[jira] [Commented] (CAMEL-18328) RouteConfiguration with RouteTemplate doesn't work
[
https://issues.apache.org/jira/browse/CAMEL-18328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17575588#comment-17575588
]
Rhuan Rocha commented on CAMEL-18328:
-
Hi, I`ll send a PR soon.
> RouteConfiguration with RouteTemplate doesn't work
> --
>
> Key: CAMEL-18328
> URL: https://issues.apache.org/jira/browse/CAMEL-18328
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 3.18.0
>Reporter: Raymond
>Priority: Minor
> Fix For: 3.18.1, 3.19.0
>
>
> I have loaded a routeConfiguration:
> {code:java}
>
>
> java.lang.Exception
>
> true
>
> redeliveryDelay="5000"/>
>
>
>
> {code}
> I have a RouteTemplate:
> {code:java}
> routeTemplate("myTemplate")
> .templateParameter("in")
> .templateParameter("out")
> .from("{{in}}")
> .routeConfigurationId("myError")
> .to("{{out}}");{code}
> But this routeConfigurationId doesn't seem to take effect. When calling the
> routeConfigurationId directly from a route is works.
> Can you reproduce this?
> BTW: What I try to achieve:
> {code:java}
> routeTemplate("myTemplate")
>
> .templateParameter("routeconfiguration_id","defaultErrorHandler")
> .templateParameter("in")
> .templateParameter("out")
> .from("{{in}}")
> .routeConfigurationId("{{routeconfiguration_id}}")
> .to("{{out}}");{code}
> Thus adding the routeConfigurationID through a templateParameter.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CAMEL-16287) camel-aws2-sqs should use pagination for deciding which aws sqs queues it should create
[ https://issues.apache.org/jira/browse/CAMEL-16287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-16287. - Resolution: Fixed > camel-aws2-sqs should use pagination for deciding which aws sqs queues it > should create > --- > > Key: CAMEL-16287 > URL: https://issues.apache.org/jira/browse/CAMEL-16287 > Project: Camel > Issue Type: Bug >Affects Versions: 2.25.3, 3.8.0 >Reporter: Gyorgy Abraham >Assignee: Andrea Cosentino >Priority: Major > Fix For: 3.14.5, 3.18.1, 3.19.0 > > > There is an auto create queue feature for aws-sqs in camel-sqs component. > Upon camel context creation / route building, it issues an API call to list > all sqs queues, so it skips the creation for already existing ones. If camel > context has a for example consumer route for an sqs queue that is not listed > in the response of this API call, camel will try to to create it. > However, this API only lists the first 1000 queues in the current account. If > there are more then 1000 queues, camel-sqs will try to create a new one, and > might fail. In our company's account, we have 1442 queues in our account and > Camel tried to create a .fifo queue because it thought it wasnt already > existing, resulting in application startup error. > Relevant code: > [https://github.com/apache/camel/blob/master/components/camel-aws2-sqs/src/main/java/org/apache/camel/component/aws2/sqs/Sqs2Endpoint.java#L174] > Relevant API docs at AWS: > [https://docs.aws.amazon.com/AWSJavaSDK/latest/javadoc/com/amazonaws/services/sqs/AmazonSQS.html#listQueues-com.amazonaws.services.sqs.model.ListQueuesRequest-] > Solution is straightforward: use pagination and load all queues. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-16287) camel-aws2-sqs should use pagination for deciding which aws sqs queues it should create
[ https://issues.apache.org/jira/browse/CAMEL-16287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-16287: Fix Version/s: 3.14.5 3.18.1 3.19.0 (was: 3.18.0) (was: 3.14.4) > camel-aws2-sqs should use pagination for deciding which aws sqs queues it > should create > --- > > Key: CAMEL-16287 > URL: https://issues.apache.org/jira/browse/CAMEL-16287 > Project: Camel > Issue Type: Bug >Affects Versions: 2.25.3, 3.8.0 >Reporter: Gyorgy Abraham >Assignee: Andrea Cosentino >Priority: Major > Fix For: 3.14.5, 3.18.1, 3.19.0 > > > There is an auto create queue feature for aws-sqs in camel-sqs component. > Upon camel context creation / route building, it issues an API call to list > all sqs queues, so it skips the creation for already existing ones. If camel > context has a for example consumer route for an sqs queue that is not listed > in the response of this API call, camel will try to to create it. > However, this API only lists the first 1000 queues in the current account. If > there are more then 1000 queues, camel-sqs will try to create a new one, and > might fail. In our company's account, we have 1442 queues in our account and > Camel tried to create a .fifo queue because it thought it wasnt already > existing, resulting in application startup error. > Relevant code: > [https://github.com/apache/camel/blob/master/components/camel-aws2-sqs/src/main/java/org/apache/camel/component/aws2/sqs/Sqs2Endpoint.java#L174] > Relevant API docs at AWS: > [https://docs.aws.amazon.com/AWSJavaSDK/latest/javadoc/com/amazonaws/services/sqs/AmazonSQS.html#listQueues-com.amazonaws.services.sqs.model.ListQueuesRequest-] > Solution is straightforward: use pagination and load all queues. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-18353) camel-test - Upgrade to JUnit 5.9.x
Claus Ibsen created CAMEL-18353: --- Summary: camel-test - Upgrade to JUnit 5.9.x Key: CAMEL-18353 URL: https://issues.apache.org/jira/browse/CAMEL-18353 Project: Camel Issue Type: Dependency upgrade Components: camel-test Reporter: Claus Ibsen Fix For: 3.19.0 There is a new 5.9.0 release and we use 5.8.x currently. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-18301) Component for Sharepoint Lists (Office 365)
[ https://issues.apache.org/jira/browse/CAMEL-18301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17575460#comment-17575460 ] Adrien SALES commented on CAMEL-18301: -- Hmmn thanks a lot for the comments Andrea. There is a SDK called "Microsoft Graph SDK " : [https://docs.microsoft.com/en-us/graph/sdks/sdks-overview] ... that wraps on top of the API : [https://docs.microsoft.com/en-us/graph/api/list-get?view=graph-rest-1.0=http] And the REST service [https://docs.microsoft.com/en-us/sharepoint/dev/sp-add-ins/working-with-lists-and-list-items-with-rest] I gues, using the REST API would be the best choice. > Component for Sharepoint Lists (Office 365) > --- > > Key: CAMEL-18301 > URL: https://issues.apache.org/jira/browse/CAMEL-18301 > Project: Camel > Issue Type: New Feature >Reporter: Adrien SALES >Priority: Minor > Labels: features > > h1. Context > > more and more users store data in Sharepoint LIsts on sharepointOnline. The > tricky part comes when we are asked to perform integrations with these DATAs. > They are served as REST APIs, OIDC and oAUth options are available but you be > awesome to be able to grab these datas as easily as we can with the JDBC > component for example. > > Our main usecase by the way is to copy data from SharepointLists to JDBC data > sources... or Kafka topics. > > h1. Feature request > > * Add the Microsoft Sharepoint List component to core components > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-18301) Component for Sharepoint Lists (Office 365)
[ https://issues.apache.org/jira/browse/CAMEL-18301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17575369#comment-17575369 ] Andrea Cosentino commented on CAMEL-18301: -- So this would require an http component dealing with their REST Api. > Component for Sharepoint Lists (Office 365) > --- > > Key: CAMEL-18301 > URL: https://issues.apache.org/jira/browse/CAMEL-18301 > Project: Camel > Issue Type: New Feature >Reporter: Adrien SALES >Priority: Minor > Labels: features > > h1. Context > > more and more users store data in Sharepoint LIsts on sharepointOnline. The > tricky part comes when we are asked to perform integrations with these DATAs. > They are served as REST APIs, OIDC and oAUth options are available but you be > awesome to be able to grab these datas as easily as we can with the JDBC > component for example. > > Our main usecase by the way is to copy data from SharepointLists to JDBC data > sources... or Kafka topics. > > h1. Feature request > > * Add the Microsoft Sharepoint List component to core components > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-18301) Component for Sharepoint Lists (Office 365)
[ https://issues.apache.org/jira/browse/CAMEL-18301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17575368#comment-17575368 ] Andrea Cosentino commented on CAMEL-18301: -- As far as I see there is not an sdk to deal with Sharepoint. > Component for Sharepoint Lists (Office 365) > --- > > Key: CAMEL-18301 > URL: https://issues.apache.org/jira/browse/CAMEL-18301 > Project: Camel > Issue Type: New Feature >Reporter: Adrien SALES >Priority: Minor > Labels: features > > h1. Context > > more and more users store data in Sharepoint LIsts on sharepointOnline. The > tricky part comes when we are asked to perform integrations with these DATAs. > They are served as REST APIs, OIDC and oAUth options are available but you be > awesome to be able to grab these datas as easily as we can with the JDBC > component for example. > > Our main usecase by the way is to copy data from SharepointLists to JDBC data > sources... or Kafka topics. > > h1. Feature request > > * Add the Microsoft Sharepoint List component to core components > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-17906) Camel REST - Multipart REST service broken in Camel 3.12+
[
https://issues.apache.org/jira/browse/CAMEL-17906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17575327#comment-17575327
]
Claus Ibsen commented on CAMEL-17906:
-
Can you update to 3.18.x or 3.19.0-SNAPSHOT and add information how to turn off
oauth.
> Camel REST - Multipart REST service broken in Camel 3.12+
> -
>
> Key: CAMEL-17906
> URL: https://issues.apache.org/jira/browse/CAMEL-17906
> Project: Camel
> Issue Type: Bug
> Components: camel-servlet
>Affects Versions: 3.12.0, 3.14.2
>Reporter: Vincent Paturet
>Priority: Minor
>
> After upgrading from Camel 3.11.5 to Camel 3.12.0, we experience a regression
> in a REST service that consumes multipart/form-data.
> (Camel REST + Camel servlet + Tomcat + Spring Boot 2.6.4 + Spring Security +
> OAuth2)
> When retrieving the binary attachment stored as an InputStream in the message
> body, the attachment is empty:
>
> {code:java}
> byte[] content = IOUtils.toByteArray(e.getIn().getBody(InputStream.class))
> <-- empty byte array {code}
> * The only code change is the upgrade from Camel 3.11.5 to 3.12
> * When disabling the OAuth2 authentication/authorization layer, the REST
> service works as expected.
> * Tested with Camel 3.14.2 with the same outcome
> * possibly related to CAMEL-17004
> stacktrace with OAuth2 enabled:
> {code:java}
> convertBodyToFileItems:97, FileUploadRouteBuilder
> (no.rutebanken.marduk.routes.file)
> process:-1, 382032327
> (no.rutebanken.marduk.routes.file.FileUploadRouteBuilder$$Lambda$1784)
> process:66, DelegateSyncProcessor (org.apache.camel.support.processor)
> doRun:810, RedeliveryErrorHandler$RedeliveryTask
> (org.apache.camel.processor.errorhandler)
> run:718, RedeliveryErrorHandler$RedeliveryTask
> (org.apache.camel.processor.errorhandler)
> schedule:179, DefaultReactiveExecutor$Worker (org.apache.camel.impl.engine)
> scheduleSync:69, DefaultReactiveExecutor (org.apache.camel.impl.engine)
> process:214, RedeliveryErrorHandler (org.apache.camel.processor.errorhandler)
> access$201:45, TransactionErrorHandler (org.apache.camel.spring.spi)
> process:247, TransactionErrorHandler$2 (org.apache.camel.spring.spi)
> process:83, DefaultAsyncProcessorAwaitManager (org.apache.camel.impl.engine)
> processByErrorHandler:244, TransactionErrorHandler
> (org.apache.camel.spring.spi)
> doInTransactionWithoutResult:207, TransactionErrorHandler$1
> (org.apache.camel.spring.spi)
> doInTransaction:36, TransactionCallbackWithoutResult
> (org.springframework.transaction.support)
> execute:140, TransactionTemplate (org.springframework.transaction.support)
> doInTransactionTemplate:200, TransactionErrorHandler
> (org.apache.camel.spring.spi)
> processInTransaction:155, TransactionErrorHandler
> (org.apache.camel.spring.spi)
> process:123, TransactionErrorHandler (org.apache.camel.spring.spi)
> process:132, TransactionErrorHandler (org.apache.camel.spring.spi)
> process:399, CamelInternalProcessor (org.apache.camel.impl.engine)
> run:109, Pipeline$PipelineTask (org.apache.camel.processor)
> schedule:179, DefaultReactiveExecutor$Worker (org.apache.camel.impl.engine)
> scheduleMain:64, DefaultReactiveExecutor (org.apache.camel.impl.engine)
> process:184, Pipeline (org.apache.camel.processor)
> process:399, CamelInternalProcessor (org.apache.camel.impl.engine)
> process:83, DefaultAsyncProcessorAwaitManager (org.apache.camel.impl.engine)
> process:41, AsyncProcessorSupport (org.apache.camel.support)
> doExecute:319, CamelServlet (org.apache.camel.http.common)
> doService:214, CamelServlet (org.apache.camel.http.common)
> service:130, CamelServlet (org.apache.camel.http.common)
> service:764, HttpServlet (javax.servlet.http)
> internalDoFilter:227, ApplicationFilterChain (org.apache.catalina.core)
> doFilter:162, ApplicationFilterChain (org.apache.catalina.core)
> doFilter:53, WsFilter (org.apache.tomcat.websocket.server)
> internalDoFilter:189, ApplicationFilterChain (org.apache.catalina.core)
> doFilter:162, ApplicationFilterChain (org.apache.catalina.core)
> doFilter:327, FilterChainProxy$VirtualFilterChain
> (org.springframework.security.web)
> invoke:115, FilterSecurityInterceptor
> (org.springframework.security.web.access.intercept)
> doFilter:81, FilterSecurityInterceptor
> (org.springframework.security.web.access.intercept)
> doFilter:336, FilterChainProxy$VirtualFilterChain
> (org.springframework.security.web)
> doFilter:122, ExceptionTranslationFilter
> (org.springframework.security.web.access)
> doFilter:116, ExceptionTranslationFilter
> (org.springframework.security.web.access)
> doFilter:336, FilterChainProxy$VirtualFilterChain
> (org.springframework.security.web)
> doFilter:126, SessionManagementFilter
> (org.springframework.security.web.session)
> doFilter:81, SessionManagementFilter
>
[jira] [Resolved] (CAMEL-18182) Camel servlet file upload with multipart/form-data not success
[ https://issues.apache.org/jira/browse/CAMEL-18182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-18182. - Resolution: Cannot Reproduce With latest release then I can get the form-data username and password. 2022-08-04 18:01:22.499 INFO 84597 --- [nio-8080-exec-1] c.l.route.ServletFormDataRouteBuilder: requestMethod-->POST --WebKitFormBoundaryBAPaDgMZzii4INuD Content-Disposition: form-data; name="username" donald --WebKitFormBoundaryBAPaDgMZzii4INuD Content-Disposition: form-data; name="password" duck --WebKitFormBoundaryBAPaDgMZzii4INuD-- > Camel servlet file upload with multipart/form-data not success > -- > > Key: CAMEL-18182 > URL: https://issues.apache.org/jira/browse/CAMEL-18182 > Project: Camel > Issue Type: Bug > Components: camel-servlet >Affects Versions: 3.14.2 >Reporter: birkh >Priority: Minor > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-18275) onCompletion tasks don't get executed in a pipeline with several SEDA queues
[
https://issues.apache.org/jira/browse/CAMEL-18275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karen Lease resolved CAMEL-18275.
-
Resolution: Fixed
> onCompletion tasks don't get executed in a pipeline with several SEDA queues
>
>
> Key: CAMEL-18275
> URL: https://issues.apache.org/jira/browse/CAMEL-18275
> Project: Camel
> Issue Type: Bug
> Components: came-core
>Affects Versions: 3.18.0
>Reporter: Eduard Gomoliako
>Assignee: Karen Lease
>Priority: Major
> Fix For: 3.19.0
>
>
> I stumbled upon a problem with not working {{onCompletion}} between the
> routes that pass a message over SEDA queues.
> The route configuration is similar to this simplified version:
>
> {code:java}
> from("direct:a")
> .onCompletion().log("a - done").end()
> .to("seda:b");
> from("seda:b")
> .onCompletion().log("b - done").end()
> .to("seda:c");
> from("seda:c")
> .onCompletion().log("c - done").end()
> .to("seda:d");
> from("seda:d")
> .onCompletion().log("d - done").end()
> .to("mock:end"); {code}
>
> With this configuration, I get only {{"d - done"}} logging.
> I debugged the execution and noticed that the {{onCompletion}} handler from
> "a", "b", and "c" don't get executed because they are route-scoped and get
> attempted to be executed in the scope of the next route.
> This happens because they get handed over from the initial exchange to an
> exchange prepared for the next route. It happens in the
> {{SedaProducer::addToQueue}} method with {{{}copy{}}}parameter defined as
> {{{}true{}}}, which makes the {{::prepareCopy}} method being called, which in
> its turn calls {{ExchangeHelper.createCorrelatedCopy}} with {{handover}}
> defined as {{{}true{}}}.
> It seems to me like a bug, because looking at the routes configuration I'd
> expect different behavior: all the {{onCompletion}} tasks get executed
> reporting on routes finalization. Though maybe I'm missing something here,
> and if this is the case then I would appreciate you guys helping me to find
> out the missing details.
> Here is a [unit test reproducing the
> problem|https://gist.github.com/Gems/7555776feae619ac71ed8d9dd9d4d33e].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-18182) Camel servlet file upload with multipart/form-data not success
[ https://issues.apache.org/jira/browse/CAMEL-18182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-18182: Fix Version/s: 3.19.0 > Camel servlet file upload with multipart/form-data not success > -- > > Key: CAMEL-18182 > URL: https://issues.apache.org/jira/browse/CAMEL-18182 > Project: Camel > Issue Type: Bug > Components: camel-servlet >Affects Versions: 3.14.2 >Reporter: birkh >Priority: Minor > Fix For: 3.19.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-18345) EMPTY_ELEMENT_AS_NULL disabled by default in jackson-dataformat-xml
[
https://issues.apache.org/jira/browse/CAMEL-18345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-18345.
-
Fix Version/s: 3.18.1
Resolution: Fixed
You can now set those xml parser features as well the same way as the others.
> EMPTY_ELEMENT_AS_NULL disabled by default in jackson-dataformat-xml
> ---
>
> Key: CAMEL-18345
> URL: https://issues.apache.org/jira/browse/CAMEL-18345
> Project: Camel
> Issue Type: Improvement
> Components: camel-jacksonxml
>Affects Versions: 3.3.0
>Reporter: José Bustamante
>Assignee: Claus Ibsen
>Priority: Major
> Fix For: 3.18.1, 3.19.0
>
> Attachments: image-2022-08-04-11-36-25-666.png,
> image-2022-08-04-11-41-09-007.png, image-2022-08-04-11-48-11-568.png
>
>
> Jackson 2.12.x changed the default for the 'EMPTY_ELEMENT_AS_NULL' feature
> from true to false (see
> [here|[https://github.com/FasterXML/jackson-dataformat-xml/issues/411]]) and
> we can enable back this property using XMLMapper:
> {quote}xmlMapper.configure(FromXmlParser.Feature.EMPTY_ELEMENT_AS_NULL, true);
> {quote}
> However, there's no way to enable this behaviour in jaxonxml inside camel
> routes. In the
> [documentation|[https://camel.apache.org/components/3.14.x/dataformats/jacksonxml-dataformat.html#_enabling_or_disable_features_using_jackson],]
> It's specified that we can enable or disable certain types of properties
> that are inside SerializationFeature, DeserializationFeature and
> MapperFeature but there's no way to enable EMPTY_ELEMENT_AS_NULL since is in
> another enum (FromXmlParser). We've tried enabling the feature
> ACCEPT_EMPTY_STRING_AS_NULL_OBJECT but that doesn't work either.
> We've managed to implement a workaround by using instead of
> in our camel routes (we use Camel XML DSL), but that's not
> efficient as we would have to replace all references. So we need
> to have the possibility to enable back EMPTY_ELEMENT_AS_NULL from
> in camel XML DSL.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (CAMEL-18345) EMPTY_ELEMENT_AS_NULL disabled by default in jackson-dataformat-xml
[
https://issues.apache.org/jira/browse/CAMEL-18345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen reassigned CAMEL-18345:
---
Assignee: Claus Ibsen
> EMPTY_ELEMENT_AS_NULL disabled by default in jackson-dataformat-xml
> ---
>
> Key: CAMEL-18345
> URL: https://issues.apache.org/jira/browse/CAMEL-18345
> Project: Camel
> Issue Type: Improvement
> Components: camel-jacksonxml
>Affects Versions: 3.3.0
>Reporter: José Bustamante
>Assignee: Claus Ibsen
>Priority: Major
> Fix For: 3.19.0
>
> Attachments: image-2022-08-04-11-36-25-666.png,
> image-2022-08-04-11-41-09-007.png, image-2022-08-04-11-48-11-568.png
>
>
> Jackson 2.12.x changed the default for the 'EMPTY_ELEMENT_AS_NULL' feature
> from true to false (see
> [here|[https://github.com/FasterXML/jackson-dataformat-xml/issues/411]]) and
> we can enable back this property using XMLMapper:
> {quote}xmlMapper.configure(FromXmlParser.Feature.EMPTY_ELEMENT_AS_NULL, true);
> {quote}
> However, there's no way to enable this behaviour in jaxonxml inside camel
> routes. In the
> [documentation|[https://camel.apache.org/components/3.14.x/dataformats/jacksonxml-dataformat.html#_enabling_or_disable_features_using_jackson],]
> It's specified that we can enable or disable certain types of properties
> that are inside SerializationFeature, DeserializationFeature and
> MapperFeature but there's no way to enable EMPTY_ELEMENT_AS_NULL since is in
> another enum (FromXmlParser). We've tried enabling the feature
> ACCEPT_EMPTY_STRING_AS_NULL_OBJECT but that doesn't work either.
> We've managed to implement a workaround by using instead of
> in our camel routes (we use Camel XML DSL), but that's not
> efficient as we would have to replace all references. So we need
> to have the possibility to enable back EMPTY_ELEMENT_AS_NULL from
> in camel XML DSL.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-18350) camel-kafka: combination of breakOnFirstError and maxPollRecords causes camel to reconsume all records on error
[ https://issues.apache.org/jira/browse/CAMEL-18350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-18350: Fix Version/s: 3.19.0 > camel-kafka: combination of breakOnFirstError and maxPollRecords causes camel > to reconsume all records on error > > > Key: CAMEL-18350 > URL: https://issues.apache.org/jira/browse/CAMEL-18350 > Project: Camel > Issue Type: Bug > Components: camel-kafka >Affects Versions: 3.18.0 >Reporter: Espen Andreassen >Priority: Major > Fix For: 3.19.0 > > > *Summary:* > When configuring the camel consumer with props "breakOnFirstError" = "true" > and "maxPollRecords" = "1", camel reconsumes all messages on topic on error. > Camel should only have reconsumed the failed message is such cases. > I configure the component like this to approximate an "exactly once" delivery > policy (in comibnation with manual commits). > I've created a project on github with a failing test that recreates the > issue: > [https://github.com/espeandr/camel-kafka-incorrectly-reconsumes-entire-topic-demo] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-18351) ExchangePropertyKey.SPLIT_COMPLETE not set to true after zip splitting completed
[ https://issues.apache.org/jira/browse/CAMEL-18351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17575287#comment-17575287 ] Claus Ibsen commented on CAMEL-18351: - Your code is wrong as if you want to split and aggregate in a fork/join kind of way then use splitter only, it has built-in aggregator. > ExchangePropertyKey.SPLIT_COMPLETE not set to true after zip splitting > completed > > > Key: CAMEL-18351 > URL: https://issues.apache.org/jira/browse/CAMEL-18351 > Project: Camel > Issue Type: Bug > Components: camel-zipfile >Affects Versions: 3.18.0 >Reporter: Alexander Lex >Priority: Minor > > When running the zip splitter, it splits the zip file as expected. However, > looking at the property "ExchangePropertyKey.SPLIT_COMPLETE", it shows not > the expected "true". > > Expected behaviour is the property "ExchangePropertyKey.SPLIT_COMPLETE" to be > set to true after the splitting is completed. > > Code to reproduce can be found here: > https://github.com/lx183/camel-zip-issue/blob/master/src/test/java/ZipSplitterRouteTest.java -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-18351) ExchangePropertyKey.SPLIT_COMPLETE not set to true after zip splitting completed
[ https://issues.apache.org/jira/browse/CAMEL-18351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-18351: Priority: Minor (was: Major) > ExchangePropertyKey.SPLIT_COMPLETE not set to true after zip splitting > completed > > > Key: CAMEL-18351 > URL: https://issues.apache.org/jira/browse/CAMEL-18351 > Project: Camel > Issue Type: Bug > Components: camel-zipfile >Affects Versions: 3.18.0 >Reporter: Alexander Lex >Priority: Minor > > When running the zip splitter, it splits the zip file as expected. However, > looking at the property "ExchangePropertyKey.SPLIT_COMPLETE", it shows not > the expected "true". > > Expected behaviour is the property "ExchangePropertyKey.SPLIT_COMPLETE" to be > set to true after the splitting is completed. > > Code to reproduce can be found here: > https://github.com/lx183/camel-zip-issue/blob/master/src/test/java/ZipSplitterRouteTest.java -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-18349) Core - XPathRouteConcurrentBigTest - newly added limit of "operators an XPath expression can contain." fails the test
[
https://issues.apache.org/jira/browse/CAMEL-18349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-18349:
Fix Version/s: 3.19.0
> Core - XPathRouteConcurrentBigTest - newly added limit of "operators an XPath
> expression can contain." fails the test
> -
>
> Key: CAMEL-18349
> URL: https://issues.apache.org/jira/browse/CAMEL-18349
> Project: Camel
> Issue Type: Test
> Components: tests
>Affects Versions: 3.19.0
>Reporter: Jiri Ondrusek
>Assignee: Jiri Ondrusek
>Priority: Minor
> Fix For: 3.19.0
>
>
> In java 11.0.15, there is a security limitation for "the number of operators
> an XPath expression can contain. (see [release
> notes|https://www.oracle.com/java/technologies/javase/11-0-15-relnotes.html])
> with default value 100.
> Unfortunately the test _XPathRouteConcurrentBigTest_ requires 101
> {code:java}
> Caused by: javax.xml.transform.TransformerException: JAXP0801002: the
> compiler encountered an XPath expression containing '101' operators that
> exceeds the '100' limit set by 'FEATURE_SECURE_PROCESSING'.
> {code}
> Solution would be to change a test little bit, to require <= 100 operations.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-18349) Core - XPathRouteConcurrentBigTest - newly added limit of "operators an XPath expression can contain." fails the test
[
https://issues.apache.org/jira/browse/CAMEL-18349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-18349:
Issue Type: Test (was: Bug)
> Core - XPathRouteConcurrentBigTest - newly added limit of "operators an XPath
> expression can contain." fails the test
> -
>
> Key: CAMEL-18349
> URL: https://issues.apache.org/jira/browse/CAMEL-18349
> Project: Camel
> Issue Type: Test
> Components: tests
>Affects Versions: 3.19.0
>Reporter: Jiri Ondrusek
>Assignee: Jiri Ondrusek
>Priority: Minor
>
> In java 11.0.15, there is a security limitation for "the number of operators
> an XPath expression can contain. (see [release
> notes|https://www.oracle.com/java/technologies/javase/11-0-15-relnotes.html])
> with default value 100.
> Unfortunately the test _XPathRouteConcurrentBigTest_ requires 101
> {code:java}
> Caused by: javax.xml.transform.TransformerException: JAXP0801002: the
> compiler encountered an XPath expression containing '101' operators that
> exceeds the '100' limit set by 'FEATURE_SECURE_PROCESSING'.
> {code}
> Solution would be to change a test little bit, to require <= 100 operations.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CAMEL-18352) Camel-AWS Cloudtrail: Create an SB starter
[ https://issues.apache.org/jira/browse/CAMEL-18352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrea Cosentino resolved CAMEL-18352. -- Resolution: Fixed > Camel-AWS Cloudtrail: Create an SB starter > -- > > Key: CAMEL-18352 > URL: https://issues.apache.org/jira/browse/CAMEL-18352 > Project: Camel > Issue Type: New Feature > Components: camel-spring-boot >Reporter: Andrea Cosentino >Assignee: Andrea Cosentino >Priority: Major > Fix For: 3.19.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-18351) ExchangePropertyKey.SPLIT_COMPLETE not set to true after zip splitting completed
[ https://issues.apache.org/jira/browse/CAMEL-18351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17575273#comment-17575273 ] Alexander Lex commented on CAMEL-18351: --- Also, it seems like the issue comes from the ZipIterator hasNext method > ExchangePropertyKey.SPLIT_COMPLETE not set to true after zip splitting > completed > > > Key: CAMEL-18351 > URL: https://issues.apache.org/jira/browse/CAMEL-18351 > Project: Camel > Issue Type: Bug > Components: camel-zipfile >Affects Versions: 3.18.0 >Reporter: Alexander Lex >Priority: Major > > When running the zip splitter, it splits the zip file as expected. However, > looking at the property "ExchangePropertyKey.SPLIT_COMPLETE", it shows not > the expected "true". > > Expected behaviour is the property "ExchangePropertyKey.SPLIT_COMPLETE" to be > set to true after the splitting is completed. > > Code to reproduce can be found here: > https://github.com/lx183/camel-zip-issue/blob/master/src/test/java/ZipSplitterRouteTest.java -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-18351) ExchangePropertyKey.SPLIT_COMPLETE not set to true after zip splitting completed
[
https://issues.apache.org/jira/browse/CAMEL-18351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17575269#comment-17575269
]
Alexander Lex commented on CAMEL-18351:
---
.split(new ZipSplitter()) .streaming() .aggregate(constant(true), new
ZipAggregationStrategy(true, true)) .completionPredicate(new Predicate() \{
@Override public boolean matches(Exchange exchange) { return
exchange.getProperty(ExchangePropertyKey.SPLIT_COMPLETE, Boolean.FALSE,
Boolean.class); } }).eagerCheckCompletion()
The code will not finish
> ExchangePropertyKey.SPLIT_COMPLETE not set to true after zip splitting
> completed
>
>
> Key: CAMEL-18351
> URL: https://issues.apache.org/jira/browse/CAMEL-18351
> Project: Camel
> Issue Type: Bug
> Components: camel-zipfile
>Affects Versions: 3.18.0
>Reporter: Alexander Lex
>Priority: Major
>
> When running the zip splitter, it splits the zip file as expected. However,
> looking at the property "ExchangePropertyKey.SPLIT_COMPLETE", it shows not
> the expected "true".
>
> Expected behaviour is the property "ExchangePropertyKey.SPLIT_COMPLETE" to be
> set to true after the splitting is completed.
>
> Code to reproduce can be found here:
> https://github.com/lx183/camel-zip-issue/blob/master/src/test/java/ZipSplitterRouteTest.java
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-18350) camel-kafka: combination of breakOnFirstError and maxPollRecords causes camel to reconsume all records on error
[ https://issues.apache.org/jira/browse/CAMEL-18350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Espen Andreassen updated CAMEL-18350: - Description: *Summary:* When configuring the camel consumer with props "breakOnFirstError" = "true" and "maxPollRecords" = "1", camel reconsumes all messages on topic on error. Camel should only have reconsumed the failed message is such cases. I configure the component like this to approximate an "exactly once" delivery policy (in comibnation with manual commits). I've created a project on github with a failing test that recreates the issue: [https://github.com/espeandr/camel-kafka-incorrectly-reconsumes-entire-topic-demo] was: *Summary:* When configuring the camel consumer with props "breakOnFirstError" = "true" and "maxPollRecords" = "1", camel reconsumes all messages on topic on error. I suspect that a offset = 0 is commited by camel is such cases. Camel should only have reconsumed the failed message is such cases. I configure the component like this to approximate an "exactly once" delivery policy (in comibnation with manual commits). I've created a project on github with a failing test that recreates the issue: https://github.com/espeandr/camel-kafka-incorrectly-reconsumes-entire-topic-demo > camel-kafka: combination of breakOnFirstError and maxPollRecords causes camel > to reconsume all records on error > > > Key: CAMEL-18350 > URL: https://issues.apache.org/jira/browse/CAMEL-18350 > Project: Camel > Issue Type: Bug > Components: camel-kafka >Affects Versions: 3.18.0 >Reporter: Espen Andreassen >Priority: Major > > *Summary:* > When configuring the camel consumer with props "breakOnFirstError" = "true" > and "maxPollRecords" = "1", camel reconsumes all messages on topic on error. > Camel should only have reconsumed the failed message is such cases. > I configure the component like this to approximate an "exactly once" delivery > policy (in comibnation with manual commits). > I've created a project on github with a failing test that recreates the > issue: > [https://github.com/espeandr/camel-kafka-incorrectly-reconsumes-entire-topic-demo] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-18352) Camel-AWS Cloudtrail: Create an SB starter
[ https://issues.apache.org/jira/browse/CAMEL-18352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrea Cosentino updated CAMEL-18352: - Summary: Camel-AWS Cloudtrail: Create an SB starter (was: Camel-AWS Cloud trail: Create an SB starter) > Camel-AWS Cloudtrail: Create an SB starter > -- > > Key: CAMEL-18352 > URL: https://issues.apache.org/jira/browse/CAMEL-18352 > Project: Camel > Issue Type: New Feature > Components: camel-spring-boot >Reporter: Andrea Cosentino >Assignee: Andrea Cosentino >Priority: Major > Fix For: 3.19.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-18352) Camel-AWS Cloud trail: Create an SB starter
Andrea Cosentino created CAMEL-18352: Summary: Camel-AWS Cloud trail: Create an SB starter Key: CAMEL-18352 URL: https://issues.apache.org/jira/browse/CAMEL-18352 Project: Camel Issue Type: New Feature Components: camel-spring-boot Reporter: Andrea Cosentino Assignee: Andrea Cosentino Fix For: 3.19.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-18350) camel-kafka: combination of breakOnFirstError and maxPollRecords causes camel to reconsume all records on error
[ https://issues.apache.org/jira/browse/CAMEL-18350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Espen Andreassen updated CAMEL-18350: - Description: *Summary:* When configuring the camel consumer with props "breakOnFirstError" = "true" and "maxPollRecords" = "1", camel reconsumes all messages on topic on error. I suspect that a offset = 0 is commited by camel is such cases. Camel should only have reconsumed the failed message is such cases. I configure the component like this to approximate an "exactly once" delivery policy (in comibnation with manual commits). I've created a project on github with a failing test that recreates the issue: https://github.com/espeandr/camel-kafka-incorrectly-reconsumes-entire-topic-demo was: *Summary:* When configuring the camel consumer with props "breakOnFirstError" = "true" and "maxPollRecords" = "1", camel reconsumes all messages on topic on error. I suspect that a offset = 0 is commited by camel is such cases. I configure the component like this to approximate an "exactly once" delivery policy (in comibnation with manual commits). I've created a project on github with a failing test that recreates the issue: > camel-kafka: combination of breakOnFirstError and maxPollRecords causes camel > to reconsume all records on error > > > Key: CAMEL-18350 > URL: https://issues.apache.org/jira/browse/CAMEL-18350 > Project: Camel > Issue Type: Bug > Components: camel-kafka >Affects Versions: 3.18.0 >Reporter: Espen Andreassen >Priority: Major > > *Summary:* > When configuring the camel consumer with props "breakOnFirstError" = "true" > and "maxPollRecords" = "1", camel reconsumes all messages on topic on error. > I suspect that a offset = 0 is commited by camel is such cases. Camel should > only have reconsumed the failed message is such cases. > I configure the component like this to approximate an "exactly once" delivery > policy (in comibnation with manual commits). > I've created a project on github with a failing test that recreates the > issue: > https://github.com/espeandr/camel-kafka-incorrectly-reconsumes-entire-topic-demo -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-18351) ExchangePropertyKey.SPLIT_COMPLETE not set to true after zip splitting completed
Alexander Lex created CAMEL-18351: - Summary: ExchangePropertyKey.SPLIT_COMPLETE not set to true after zip splitting completed Key: CAMEL-18351 URL: https://issues.apache.org/jira/browse/CAMEL-18351 Project: Camel Issue Type: Bug Components: camel-zipfile Affects Versions: 3.18.0 Reporter: Alexander Lex When running the zip splitter, it splits the zip file as expected. However, looking at the property "ExchangePropertyKey.SPLIT_COMPLETE", it shows not the expected "true". Expected behaviour is the property "ExchangePropertyKey.SPLIT_COMPLETE" to be set to true after the splitting is completed. Code to reproduce can be found here: https://github.com/lx183/camel-zip-issue/blob/master/src/test/java/ZipSplitterRouteTest.java -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-18350) camel-kafka: combination of breakOnFirstError and maxPollRecords causes camel to reconsume all records on error
Espen Andreassen created CAMEL-18350: Summary: camel-kafka: combination of breakOnFirstError and maxPollRecords causes camel to reconsume all records on error Key: CAMEL-18350 URL: https://issues.apache.org/jira/browse/CAMEL-18350 Project: Camel Issue Type: Bug Components: camel-kafka Affects Versions: 3.18.0 Reporter: Espen Andreassen *Summary:* When configuring the camel consumer with props "breakOnFirstError" = "true" and "maxPollRecords" = "1", camel reconsumes all messages on topic on error. I suspect that a offset = 0 is commited by camel is such cases. I configure the component like this to approximate an "exactly once" delivery policy (in comibnation with manual commits). I've created a project on github with a failing test that recreates the issue: -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-18347) camel-test-infra: instances are not properly singleton
[ https://issues.apache.org/jira/browse/CAMEL-18347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Otavio Rodolfo Piske updated CAMEL-18347: - Summary: camel-test-infra: instances are not properly singleton (was: camel-test-infra-kafka: instances are not properly singleton) > camel-test-infra: instances are not properly singleton > -- > > Key: CAMEL-18347 > URL: https://issues.apache.org/jira/browse/CAMEL-18347 > Project: Camel > Issue Type: Bug > Components: camel-test-infra-kafka >Affects Versions: 3.18.0, 3.19.0 >Reporter: Otavio Rodolfo Piske >Priority: Major > > Despite being advertised as singleton, the test infra still create multiple > instances of the services. This can slow down test execution and use more > resources than necessary. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-18347) camel-test-infra: instances are not properly singleton
[ https://issues.apache.org/jira/browse/CAMEL-18347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Otavio Rodolfo Piske updated CAMEL-18347: - Component/s: camel-test-infra-arangodb camel-test-infra-hbase camel-test-infra-mongodb > camel-test-infra: instances are not properly singleton > -- > > Key: CAMEL-18347 > URL: https://issues.apache.org/jira/browse/CAMEL-18347 > Project: Camel > Issue Type: Bug > Components: camel-test-infra-arangodb, camel-test-infra-hbase, > camel-test-infra-kafka, camel-test-infra-mongodb >Affects Versions: 3.18.0, 3.19.0 >Reporter: Otavio Rodolfo Piske >Priority: Major > > Despite being advertised as singleton, the test infra still create multiple > instances of the services. This can slow down test execution and use more > resources than necessary. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-18341) Upgrade from Codehaus Groovy 3.0.12 to Apache Groovy 4.x
[ https://issues.apache.org/jira/browse/CAMEL-18341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17575240#comment-17575240 ] Aurélien Pupier commented on CAMEL-18341: - it sounds that for Spring Boot it is better to wait Groovy upgrade in Spring Boot; Which is [done in 3.0.0-Mx|https://github.com/spring-projects/spring-boot/issues/31631]. The 3.0.0 is planned for [end of November|[https://github.com/spring-projects/spring-boot/milestone/240]]. For Quarkus, it seems that we should be able to nopt be aligned based [https://github.com/quarkusio/quarkus/issues/27111#issuecomment-1203974521] Quarkus is not planning to upgrade to Groovy 4.x due to performance regression https://issues.apache.org/jira/browse/GROOVY-10307 > Upgrade from Codehaus Groovy 3.0.12 to Apache Groovy 4.x > > > Key: CAMEL-18341 > URL: https://issues.apache.org/jira/browse/CAMEL-18341 > Project: Camel > Issue Type: Dependency upgrade >Affects Versions: 3.18.0 >Reporter: Aurélien Pupier >Assignee: Aurélien Pupier >Priority: Major > > Groovy 4.0.0 has been released at the beginning of 2022. it might be nice to > move to the latest version. > There is a long list of features and bug fixes > [http://groovy-lang.org/changelogs/changelog-4.0.0.html] > Maybe worth noticing it contains several fixes related to Java 17: > * [GROOVY-10391] - Default interface methods causing problems with java 17 > and groovy 3.0.9 > * [GROOVY-10405] - @AutoClone breaks in Java17 for File properties > * [GROOVY-10429] - StringBuilder misses setLength method in Java17 > Based on [https://groovy.apache.org/versioning.html] 3.x will have oen or two > bugfixxes release (in fact already 3 happened). So good chances that there > will be only security release of 3.x soon. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Work stopped] (CAMEL-18341) Upgrade from Codehaus Groovy 3.0.12 to Apache Groovy 4.x
[ https://issues.apache.org/jira/browse/CAMEL-18341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CAMEL-18341 stopped by Aurélien Pupier. --- > Upgrade from Codehaus Groovy 3.0.12 to Apache Groovy 4.x > > > Key: CAMEL-18341 > URL: https://issues.apache.org/jira/browse/CAMEL-18341 > Project: Camel > Issue Type: Dependency upgrade >Affects Versions: 3.18.0 >Reporter: Aurélien Pupier >Assignee: Aurélien Pupier >Priority: Major > > Groovy 4.0.0 has been released at the beginning of 2022. it might be nice to > move to the latest version. > There is a long list of features and bug fixes > [http://groovy-lang.org/changelogs/changelog-4.0.0.html] > Maybe worth noticing it contains several fixes related to Java 17: > * [GROOVY-10391] - Default interface methods causing problems with java 17 > and groovy 3.0.9 > * [GROOVY-10405] - @AutoClone breaks in Java17 for File properties > * [GROOVY-10429] - StringBuilder misses setLength method in Java17 > Based on [https://groovy.apache.org/versioning.html] 3.x will have oen or two > bugfixxes release (in fact already 3 happened). So good chances that there > will be only security release of 3.x soon. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (CAMEL-18341) Upgrade from Codehaus Groovy 3.0.12 to Apache Groovy 4.x
[ https://issues.apache.org/jira/browse/CAMEL-18341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aurélien Pupier reassigned CAMEL-18341: --- Assignee: (was: Aurélien Pupier) > Upgrade from Codehaus Groovy 3.0.12 to Apache Groovy 4.x > > > Key: CAMEL-18341 > URL: https://issues.apache.org/jira/browse/CAMEL-18341 > Project: Camel > Issue Type: Dependency upgrade >Affects Versions: 3.18.0 >Reporter: Aurélien Pupier >Priority: Major > > Groovy 4.0.0 has been released at the beginning of 2022. it might be nice to > move to the latest version. > There is a long list of features and bug fixes > [http://groovy-lang.org/changelogs/changelog-4.0.0.html] > Maybe worth noticing it contains several fixes related to Java 17: > * [GROOVY-10391] - Default interface methods causing problems with java 17 > and groovy 3.0.9 > * [GROOVY-10405] - @AutoClone breaks in Java17 for File properties > * [GROOVY-10429] - StringBuilder misses setLength method in Java17 > Based on [https://groovy.apache.org/versioning.html] 3.x will have oen or two > bugfixxes release (in fact already 3 happened). So good chances that there > will be only security release of 3.x soon. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-18349) Core - XPathRouteConcurrentBigTest - newly added limit of "operators an XPath expression can contain." fails the test
Jiri Ondrusek created CAMEL-18349:
-
Summary: Core - XPathRouteConcurrentBigTest - newly added limit of
"operators an XPath expression can contain." fails the test
Key: CAMEL-18349
URL: https://issues.apache.org/jira/browse/CAMEL-18349
Project: Camel
Issue Type: Bug
Components: tests
Affects Versions: 3.19.0
Reporter: Jiri Ondrusek
Assignee: Jiri Ondrusek
In java 11.0.15, there is a security limitation for "the number of operators
an XPath expression can contain. (see [release
notes|https://www.oracle.com/java/technologies/javase/11-0-15-relnotes.html])
with default value 100.
Unfortunately the test _XPathRouteConcurrentBigTest_ requires 101
{code:java}
Caused by: javax.xml.transform.TransformerException: JAXP0801002: the compiler
encountered an XPath expression containing '101' operators that exceeds the
'100' limit set by 'FEATURE_SECURE_PROCESSING'.
{code}
Solution would be to change a test little bit, to require <= 100 operations.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-18345) EMPTY_ELEMENT_AS_NULL disabled by default in jackson-dataformat-xml
[
https://issues.apache.org/jira/browse/CAMEL-18345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-18345:
Fix Version/s: 3.19.0
> EMPTY_ELEMENT_AS_NULL disabled by default in jackson-dataformat-xml
> ---
>
> Key: CAMEL-18345
> URL: https://issues.apache.org/jira/browse/CAMEL-18345
> Project: Camel
> Issue Type: Improvement
> Components: camel-jacksonxml
>Affects Versions: 3.3.0
>Reporter: José Bustamante
>Priority: Major
> Fix For: 3.19.0
>
> Attachments: image-2022-08-04-11-36-25-666.png,
> image-2022-08-04-11-41-09-007.png, image-2022-08-04-11-48-11-568.png
>
>
> Jackson 2.12.x changed the default for the 'EMPTY_ELEMENT_AS_NULL' feature
> from true to false (see
> [here|[https://github.com/FasterXML/jackson-dataformat-xml/issues/411]]) and
> we can enable back this property using XMLMapper:
> {quote}xmlMapper.configure(FromXmlParser.Feature.EMPTY_ELEMENT_AS_NULL, true);
> {quote}
> However, there's no way to enable this behaviour in jaxonxml inside camel
> routes. In the
> [documentation|[https://camel.apache.org/components/3.14.x/dataformats/jacksonxml-dataformat.html#_enabling_or_disable_features_using_jackson],]
> It's specified that we can enable or disable certain types of properties
> that are inside SerializationFeature, DeserializationFeature and
> MapperFeature but there's no way to enable EMPTY_ELEMENT_AS_NULL since is in
> another enum (FromXmlParser). We've tried enabling the feature
> ACCEPT_EMPTY_STRING_AS_NULL_OBJECT but that doesn't work either.
> We've managed to implement a workaround by using instead of
> in our camel routes (we use Camel XML DSL), but that's not
> efficient as we would have to replace all references. So we need
> to have the possibility to enable back EMPTY_ELEMENT_AS_NULL from
> in camel XML DSL.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CAMEL-18348) camel-yaml-dsl - Template should be named as routeTemplate
[ https://issues.apache.org/jira/browse/CAMEL-18348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-18348. - Resolution: Fixed > camel-yaml-dsl - Template should be named as routeTemplate > -- > > Key: CAMEL-18348 > URL: https://issues.apache.org/jira/browse/CAMEL-18348 > Project: Camel > Issue Type: Improvement > Components: camel-yaml-dsl >Reporter: Claus Ibsen >Assignee: Claus Ibsen >Priority: Major > Fix For: 3.19.0 > > > Route templates can be named just `template` which is too generic name. They > are named `routeTemplate` in the model and therefore we should align yaml-dsl > to use this term also. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-18348) camel-yaml-dsl - Template should be named as routeTemplate
Claus Ibsen created CAMEL-18348: --- Summary: camel-yaml-dsl - Template should be named as routeTemplate Key: CAMEL-18348 URL: https://issues.apache.org/jira/browse/CAMEL-18348 Project: Camel Issue Type: Improvement Components: camel-yaml-dsl Reporter: Claus Ibsen Assignee: Claus Ibsen Fix For: 3.19.0 Route templates can be named just `template` which is too generic name. They are named `routeTemplate` in the model and therefore we should align yaml-dsl to use this term also. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (CAMEL-18345) EMPTY_ELEMENT_AS_NULL disabled by default in jackson-dataformat-xml
[
https://issues.apache.org/jira/browse/CAMEL-18345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17575176#comment-17575176
]
José Bustamante edited comment on CAMEL-18345 at 8/4/22 9:56 AM:
-
Thanks for your reply. I just tested with latest camel (3.18.0) and the latest
jackson-dataformat-xml (2.13.3) and I'm having the same issue. I've created a
basic project with the latest camel 3 and I've implemented a small unit test.
If I use this
{quote}from("direct:start").unmarshal().jacksonXml(Header.class, true)
{quote}
I'm getting the empty object transformed (the difference in blue)
!image-2022-08-04-11-41-09-007.png|width=787,height=72!
But if I create a custom XMLMapper with the property manually enabled
{quote}.unmarshal(createCustomJacksonXMLDataformat(Header.class))
{quote}
{{The property manually enabled (in bold)}}
_private JacksonXMLDataFormat createCustomJacksonXMLDataformat(Class type){_
_JacksonXMLDataFormat dataFormat = new JacksonXMLDataFormat();_
_XmlMapper xmlMapper = new XmlMapper();_
_*xmlMapper.configure(FromXmlParser.Feature.EMPTY_ELEMENT_AS_NULL,
true);*_
_xmlMapper.configure(DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES,
false);_
_dataFormat.setXmlMapper(xmlMapper);
dataFormat.setUnmarshalType(type);_
_return dataFormat;_
_}_
It works.
!image-2022-08-04-11-48-11-568.png|width=967,height=116!
What we need is to use jacksonXml with some configuration in order to enable
this feature in our XML DSL routes, instead of creating the custom
JacksonXMLDataformat with XMLMapper. In our project we use XML DLS so
implementing this is more complex than doing it with Java DSL.
Thanks in advnace for your help
was (Author: wayqui):
Thanks for your reply. I just tested with latest camel (3.18.0) and the latest
jackson-dataformat-xml (2.13.3) and I'm having the same issue. I've created a
basic project with the latest camel 3 and I've implemented a small unit test.
If I use this
{quote}from("direct:start").unmarshal().jacksonXml(Header.class, true)
{quote}
I'm getting the empty object transformed (the difference in blue)
!image-2022-08-04-11-41-09-007.png|width=787,height=72!
But if I create a custom XMLMapper with the property manually enabled
{quote}.unmarshal(createCustomJacksonXMLDataformat(Header.class))
{quote}
{{The property manually enabled (in bold)}}
{quote}private JacksonXMLDataFormat createCustomJacksonXMLDataformat(Class
type)
Unknown macro: \{ JacksonXMLDataFormat dataFormat = new
JacksonXMLDataFormat(); XmlMapper xmlMapper = new XmlMapper();
*xmlMapper.configure(FromXmlParser.Feature.EMPTY_ELEMENT_AS_NULL, true);*
xmlMapper.configure(DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES, false);
dataFormat.setXmlMapper(xmlMapper); dataFormat.setUnmarshalType(type);
return dataFormat; }{quote}
It works.
!image-2022-08-04-11-48-11-568.png|width=967,height=116!
What we need is to use jacksonXml with some configuration in order to enable
this feature in our XML DSL routes, instead of creating the custom
JacksonXMLDataformat with XMLMapper. In our project we use XML DLS so
implementing this is more complex than doing it with Java DSL.
Thanks in advnace for your help
> EMPTY_ELEMENT_AS_NULL disabled by default in jackson-dataformat-xml
> ---
>
> Key: CAMEL-18345
> URL: https://issues.apache.org/jira/browse/CAMEL-18345
> Project: Camel
> Issue Type: Improvement
> Components: camel-jacksonxml
>Affects Versions: 3.3.0
>Reporter: José Bustamante
>Priority: Major
> Attachments: image-2022-08-04-11-36-25-666.png,
> image-2022-08-04-11-41-09-007.png, image-2022-08-04-11-48-11-568.png
>
>
> Jackson 2.12.x changed the default for the 'EMPTY_ELEMENT_AS_NULL' feature
> from true to false (see
> [here|[https://github.com/FasterXML/jackson-dataformat-xml/issues/411]]) and
> we can enable back this property using XMLMapper:
> {quote}xmlMapper.configure(FromXmlParser.Feature.EMPTY_ELEMENT_AS_NULL, true);
> {quote}
> However, there's no way to enable this behaviour in jaxonxml inside camel
> routes. In the
> [documentation|[https://camel.apache.org/components/3.14.x/dataformats/jacksonxml-dataformat.html#_enabling_or_disable_features_using_jackson],]
> It's specified that we can enable or disable certain types of properties
> that are inside SerializationFeature, DeserializationFeature and
> MapperFeature but there's no way to enable EMPTY_ELEMENT_AS_NULL since is in
> another enum (FromXmlParser). We've tried enabling the feature
> ACCEPT_EMPTY_STRING_AS_NULL_OBJECT but that doesn't work either.
> We've managed to implement a workaround by using instead of
> in our camel routes (we use Camel
[jira] [Comment Edited] (CAMEL-18345) EMPTY_ELEMENT_AS_NULL disabled by default in jackson-dataformat-xml
[
https://issues.apache.org/jira/browse/CAMEL-18345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17575176#comment-17575176
]
José Bustamante edited comment on CAMEL-18345 at 8/4/22 9:54 AM:
-
Thanks for your reply. I just tested with latest camel (3.18.0) and the latest
jackson-dataformat-xml (2.13.3) and I'm having the same issue. I've created a
basic project with the latest camel 3 and I've implemented a small unit test.
If I use this
{quote}from("direct:start").unmarshal().jacksonXml(Header.class, true)
{quote}
I'm getting the empty object transformed (the difference in blue)
!image-2022-08-04-11-41-09-007.png|width=787,height=72!
But if I create a custom XMLMapper with the property manually enabled
{quote}.unmarshal(createCustomJacksonXMLDataformat(Header.class))
{quote}
{{The property manually enabled (in bold)}}
{quote}private JacksonXMLDataFormat createCustomJacksonXMLDataformat(Class
type)
Unknown macro: \{ JacksonXMLDataFormat dataFormat = new
JacksonXMLDataFormat(); XmlMapper xmlMapper = new XmlMapper();
*xmlMapper.configure(FromXmlParser.Feature.EMPTY_ELEMENT_AS_NULL, true);*
xmlMapper.configure(DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES, false);
dataFormat.setXmlMapper(xmlMapper); dataFormat.setUnmarshalType(type);
return dataFormat; }{quote}
It works.
!image-2022-08-04-11-48-11-568.png|width=967,height=116!
What we need is to use jacksonXml with some configuration in order to enable
this feature in our XML DSL routes, instead of creating the custom
JacksonXMLDataformat with XMLMapper. In our project we use XML DLS so
implementing this is more complex than doing it with Java DSL.
Thanks in advnace for your help
was (Author: wayqui):
Thanks for your reply. I just tested with latest camel (3.18.0) and the latest
jackson-dataformat-xml (2.13.3) and I'm having the same issue. I've created a
basic project with the latest camel 3 and I've implemented a small unit test.
If I use this
{quote}from("direct:start").unmarshal().jacksonXml(Header.class, true)
{quote}
I'm getting the empty object transformed (the difference in blue)
!image-2022-08-04-11-41-09-007.png!
But if I create a custom XMLMapper with the property manually enabled
{quote}.unmarshal(createCustomJacksonXMLDataformat(Header.class)){quote}
{{The property manually enabled (in bold)}}
{quote}private JacksonXMLDataFormat createCustomJacksonXMLDataformat(Class
type) {
JacksonXMLDataFormat dataFormat = new JacksonXMLDataFormat();
XmlMapper xmlMapper = new XmlMapper();
*xmlMapper.configure(FromXmlParser.Feature.EMPTY_ELEMENT_AS_NULL, true);*
xmlMapper.configure(DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES,
false);
dataFormat.setXmlMapper(xmlMapper);
dataFormat.setUnmarshalType(type);
return dataFormat;
}
{quote}
It works.
!image-2022-08-04-11-48-11-568.png|width=967,height=116!
What we need is to use jacksonXml with some configuration in order to enable
this feature in our XML DSL routes, instead of creating the custom
JacksonXMLDataformat with XMLMapper. In our project we use XML DLS so
implementing this is more complex than doing it with Java DSL.
Thanks in advnace for your help
> EMPTY_ELEMENT_AS_NULL disabled by default in jackson-dataformat-xml
> ---
>
> Key: CAMEL-18345
> URL: https://issues.apache.org/jira/browse/CAMEL-18345
> Project: Camel
> Issue Type: Improvement
> Components: camel-jacksonxml
>Affects Versions: 3.3.0
>Reporter: José Bustamante
>Priority: Major
> Attachments: image-2022-08-04-11-36-25-666.png,
> image-2022-08-04-11-41-09-007.png, image-2022-08-04-11-48-11-568.png
>
>
> Jackson 2.12.x changed the default for the 'EMPTY_ELEMENT_AS_NULL' feature
> from true to false (see
> [here|[https://github.com/FasterXML/jackson-dataformat-xml/issues/411]]) and
> we can enable back this property using XMLMapper:
> {quote}xmlMapper.configure(FromXmlParser.Feature.EMPTY_ELEMENT_AS_NULL, true);
> {quote}
> However, there's no way to enable this behaviour in jaxonxml inside camel
> routes. In the
> [documentation|[https://camel.apache.org/components/3.14.x/dataformats/jacksonxml-dataformat.html#_enabling_or_disable_features_using_jackson],]
> It's specified that we can enable or disable certain types of properties
> that are inside SerializationFeature, DeserializationFeature and
> MapperFeature but there's no way to enable EMPTY_ELEMENT_AS_NULL since is in
> another enum (FromXmlParser). We've tried enabling the feature
> ACCEPT_EMPTY_STRING_AS_NULL_OBJECT but that doesn't work either.
> We've managed to implement a workaround by using instead of
> in our camel routes (we use Camel XML DSL), but that's not
> efficient as we would have to
[jira] [Updated] (CAMEL-18346) Remove use of Xalan
[ https://issues.apache.org/jira/browse/CAMEL-18346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] PJ Fanning updated CAMEL-18346: --- Description: Xalan-J has an unfixed CVE. It is possible that this will be fixed in the future but Xalan-J has had only one release since 2008 (in 2014). https://www.cvedetails.com/cve/CVE-2022-34169/ Java has built-in support for TransformerFactory and XPathFactory. This means most apps that use Xalan-J can readily switch away. Saxon-HE is another well maintained alternative. Places where Camel still uses Xalan: * https://github.com/apache/camel/blob/9d6ad653b6faa16e3c09047da66cd3bca94783ee/components/camel-xmlsecurity/pom.xml * https://github.com/apache/camel/blob/9d6ad653b6faa16e3c09047da66cd3bca94783ee/tooling/maven/camel-eip-documentation-enricher-maven-plugin/pom.xml#L73 There are profiles for testing in a number of poms: eg https://github.com/apache/camel/blob/main/core/camel-core-engine/pom.xml#L325 was: Xalan-J has an unfixed CVE. It is possible that this will be fixed in the future but Xalan-J has had only one release since 2008 (in 2014). https://www.cvedetails.com/cve/CVE-2022-34169/ Java has built-in support for TransformerFactory and XPathFactory. This means most apps that use Xalan-J can readily switch away. Saxon-HE is another well maintained alternative. One place where Camel still uses Xalan: https://github.com/apache/camel/blob/9d6ad653b6faa16e3c09047da66cd3bca94783ee/components/camel-xmlsecurity/pom.xml There are profiles for testing in a number of poms: eg https://github.com/apache/camel/blob/main/core/camel-core-engine/pom.xml#L325 > Remove use of Xalan > --- > > Key: CAMEL-18346 > URL: https://issues.apache.org/jira/browse/CAMEL-18346 > Project: Camel > Issue Type: Task > Components: build system >Reporter: PJ Fanning >Priority: Minor > Fix For: 3.19.0 > > > Xalan-J has an unfixed CVE. It is possible that this will be fixed in the > future but Xalan-J has had only one release since 2008 (in 2014). > https://www.cvedetails.com/cve/CVE-2022-34169/ > Java has built-in support for TransformerFactory and XPathFactory. This means > most apps that use Xalan-J can readily switch away. Saxon-HE is another well > maintained alternative. > Places where Camel still uses Xalan: > * > https://github.com/apache/camel/blob/9d6ad653b6faa16e3c09047da66cd3bca94783ee/components/camel-xmlsecurity/pom.xml > * > https://github.com/apache/camel/blob/9d6ad653b6faa16e3c09047da66cd3bca94783ee/tooling/maven/camel-eip-documentation-enricher-maven-plugin/pom.xml#L73 > There are profiles for testing in a number of poms: > eg > https://github.com/apache/camel/blob/main/core/camel-core-engine/pom.xml#L325 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-18346) Remove use of Xalan
[ https://issues.apache.org/jira/browse/CAMEL-18346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] PJ Fanning updated CAMEL-18346: --- Description: Xalan-J has an unfixed CVE. It is possible that this will be fixed in the future but Xalan-J has had only one release since 2008 (in 2014). https://www.cvedetails.com/cve/CVE-2022-34169/ Java has built-in support for TransformerFactory and XPathFactory. This means most apps that use Xalan-J can readily switch away. Saxon-HE is another well maintained alternative. One place where Camel still uses Xalan: https://github.com/apache/camel/blob/9d6ad653b6faa16e3c09047da66cd3bca94783ee/components/camel-xmlsecurity/pom.xml There are profiles for testing in a number of poms: eg https://github.com/apache/camel/blob/main/core/camel-core-engine/pom.xml#L325 was: Xalan-J has an unfixed CVE. It is possible that this will be fixed in the future but Xalan-J has had only one release since 2008 (in 2014). https://www.cvedetails.com/cve/CVE-2022-34169/ Java has built-in support for TransformerFactory and XPathFactory. This means most apps that use Xalan-J can readily switch away. Saxon-HE is another well maintained alternative. One place where Camel still uses Xalan: https://github.com/apache/camel/blob/main/core/camel-core-engine/pom.xml#L325 > Remove use of Xalan > --- > > Key: CAMEL-18346 > URL: https://issues.apache.org/jira/browse/CAMEL-18346 > Project: Camel > Issue Type: Task > Components: build system >Reporter: PJ Fanning >Priority: Minor > Fix For: 3.19.0 > > > Xalan-J has an unfixed CVE. It is possible that this will be fixed in the > future but Xalan-J has had only one release since 2008 (in 2014). > https://www.cvedetails.com/cve/CVE-2022-34169/ > Java has built-in support for TransformerFactory and XPathFactory. This means > most apps that use Xalan-J can readily switch away. Saxon-HE is another well > maintained alternative. > One place where Camel still uses Xalan: > https://github.com/apache/camel/blob/9d6ad653b6faa16e3c09047da66cd3bca94783ee/components/camel-xmlsecurity/pom.xml > There are profiles for testing in a number of poms: > eg > https://github.com/apache/camel/blob/main/core/camel-core-engine/pom.xml#L325 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-18345) EMPTY_ELEMENT_AS_NULL disabled by default in jackson-dataformat-xml
[
https://issues.apache.org/jira/browse/CAMEL-18345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
José Bustamante updated CAMEL-18345:
Attachment: image-2022-08-04-11-48-11-568.png
> EMPTY_ELEMENT_AS_NULL disabled by default in jackson-dataformat-xml
> ---
>
> Key: CAMEL-18345
> URL: https://issues.apache.org/jira/browse/CAMEL-18345
> Project: Camel
> Issue Type: Improvement
> Components: camel-jacksonxml
>Affects Versions: 3.3.0
>Reporter: José Bustamante
>Priority: Major
> Attachments: image-2022-08-04-11-36-25-666.png,
> image-2022-08-04-11-41-09-007.png, image-2022-08-04-11-48-11-568.png
>
>
> Jackson 2.12.x changed the default for the 'EMPTY_ELEMENT_AS_NULL' feature
> from true to false (see
> [here|[https://github.com/FasterXML/jackson-dataformat-xml/issues/411]]) and
> we can enable back this property using XMLMapper:
> {quote}xmlMapper.configure(FromXmlParser.Feature.EMPTY_ELEMENT_AS_NULL, true);
> {quote}
> However, there's no way to enable this behaviour in jaxonxml inside camel
> routes. In the
> [documentation|[https://camel.apache.org/components/3.14.x/dataformats/jacksonxml-dataformat.html#_enabling_or_disable_features_using_jackson],]
> It's specified that we can enable or disable certain types of properties
> that are inside SerializationFeature, DeserializationFeature and
> MapperFeature but there's no way to enable EMPTY_ELEMENT_AS_NULL since is in
> another enum (FromXmlParser). We've tried enabling the feature
> ACCEPT_EMPTY_STRING_AS_NULL_OBJECT but that doesn't work either.
> We've managed to implement a workaround by using instead of
> in our camel routes (we use Camel XML DSL), but that's not
> efficient as we would have to replace all references. So we need
> to have the possibility to enable back EMPTY_ELEMENT_AS_NULL from
> in camel XML DSL.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CAMEL-18345) EMPTY_ELEMENT_AS_NULL disabled by default in jackson-dataformat-xml
[
https://issues.apache.org/jira/browse/CAMEL-18345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17575176#comment-17575176
]
José Bustamante commented on CAMEL-18345:
-
Thanks for your reply. I just tested with latest camel (3.18.0) and the latest
jackson-dataformat-xml (2.13.3) and I'm having the same issue. I've created a
basic project with the latest camel 3 and I've implemented a small unit test.
If I use this
{quote}from("direct:start").unmarshal().jacksonXml(Header.class, true)
{quote}
I'm getting the empty object transformed (the difference in blue)
!image-2022-08-04-11-41-09-007.png!
But if I create a custom XMLMapper with the property manually enabled
{quote}.unmarshal(createCustomJacksonXMLDataformat(Header.class)){quote}
{{The property manually enabled (in bold)}}
{quote}private JacksonXMLDataFormat createCustomJacksonXMLDataformat(Class
type) {
JacksonXMLDataFormat dataFormat = new JacksonXMLDataFormat();
XmlMapper xmlMapper = new XmlMapper();
*xmlMapper.configure(FromXmlParser.Feature.EMPTY_ELEMENT_AS_NULL, true);*
xmlMapper.configure(DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES,
false);
dataFormat.setXmlMapper(xmlMapper);
dataFormat.setUnmarshalType(type);
return dataFormat;
}
{quote}
It works.
!image-2022-08-04-11-48-11-568.png|width=967,height=116!
What we need is to use jacksonXml with some configuration in order to enable
this feature in our XML DSL routes, instead of creating the custom
JacksonXMLDataformat with XMLMapper. In our project we use XML DLS so
implementing this is more complex than doing it with Java DSL.
Thanks in advnace for your help
> EMPTY_ELEMENT_AS_NULL disabled by default in jackson-dataformat-xml
> ---
>
> Key: CAMEL-18345
> URL: https://issues.apache.org/jira/browse/CAMEL-18345
> Project: Camel
> Issue Type: Improvement
> Components: camel-jacksonxml
>Affects Versions: 3.3.0
>Reporter: José Bustamante
>Priority: Major
> Attachments: image-2022-08-04-11-36-25-666.png,
> image-2022-08-04-11-41-09-007.png, image-2022-08-04-11-48-11-568.png
>
>
> Jackson 2.12.x changed the default for the 'EMPTY_ELEMENT_AS_NULL' feature
> from true to false (see
> [here|[https://github.com/FasterXML/jackson-dataformat-xml/issues/411]]) and
> we can enable back this property using XMLMapper:
> {quote}xmlMapper.configure(FromXmlParser.Feature.EMPTY_ELEMENT_AS_NULL, true);
> {quote}
> However, there's no way to enable this behaviour in jaxonxml inside camel
> routes. In the
> [documentation|[https://camel.apache.org/components/3.14.x/dataformats/jacksonxml-dataformat.html#_enabling_or_disable_features_using_jackson],]
> It's specified that we can enable or disable certain types of properties
> that are inside SerializationFeature, DeserializationFeature and
> MapperFeature but there's no way to enable EMPTY_ELEMENT_AS_NULL since is in
> another enum (FromXmlParser). We've tried enabling the feature
> ACCEPT_EMPTY_STRING_AS_NULL_OBJECT but that doesn't work either.
> We've managed to implement a workaround by using instead of
> in our camel routes (we use Camel XML DSL), but that's not
> efficient as we would have to replace all references. So we need
> to have the possibility to enable back EMPTY_ELEMENT_AS_NULL from
> in camel XML DSL.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-18345) EMPTY_ELEMENT_AS_NULL disabled by default in jackson-dataformat-xml
[
https://issues.apache.org/jira/browse/CAMEL-18345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
José Bustamante updated CAMEL-18345:
Attachment: image-2022-08-04-11-41-09-007.png
> EMPTY_ELEMENT_AS_NULL disabled by default in jackson-dataformat-xml
> ---
>
> Key: CAMEL-18345
> URL: https://issues.apache.org/jira/browse/CAMEL-18345
> Project: Camel
> Issue Type: Improvement
> Components: camel-jacksonxml
>Affects Versions: 3.3.0
>Reporter: José Bustamante
>Priority: Major
> Attachments: image-2022-08-04-11-36-25-666.png,
> image-2022-08-04-11-41-09-007.png
>
>
> Jackson 2.12.x changed the default for the 'EMPTY_ELEMENT_AS_NULL' feature
> from true to false (see
> [here|[https://github.com/FasterXML/jackson-dataformat-xml/issues/411]]) and
> we can enable back this property using XMLMapper:
> {quote}xmlMapper.configure(FromXmlParser.Feature.EMPTY_ELEMENT_AS_NULL, true);
> {quote}
> However, there's no way to enable this behaviour in jaxonxml inside camel
> routes. In the
> [documentation|[https://camel.apache.org/components/3.14.x/dataformats/jacksonxml-dataformat.html#_enabling_or_disable_features_using_jackson],]
> It's specified that we can enable or disable certain types of properties
> that are inside SerializationFeature, DeserializationFeature and
> MapperFeature but there's no way to enable EMPTY_ELEMENT_AS_NULL since is in
> another enum (FromXmlParser). We've tried enabling the feature
> ACCEPT_EMPTY_STRING_AS_NULL_OBJECT but that doesn't work either.
> We've managed to implement a workaround by using instead of
> in our camel routes (we use Camel XML DSL), but that's not
> efficient as we would have to replace all references. So we need
> to have the possibility to enable back EMPTY_ELEMENT_AS_NULL from
> in camel XML DSL.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-18345) EMPTY_ELEMENT_AS_NULL disabled by default in jackson-dataformat-xml
[
https://issues.apache.org/jira/browse/CAMEL-18345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
José Bustamante updated CAMEL-18345:
Attachment: image-2022-08-04-11-36-25-666.png
> EMPTY_ELEMENT_AS_NULL disabled by default in jackson-dataformat-xml
> ---
>
> Key: CAMEL-18345
> URL: https://issues.apache.org/jira/browse/CAMEL-18345
> Project: Camel
> Issue Type: Improvement
> Components: camel-jacksonxml
>Affects Versions: 3.3.0
>Reporter: José Bustamante
>Priority: Major
> Attachments: image-2022-08-04-11-36-25-666.png
>
>
> Jackson 2.12.x changed the default for the 'EMPTY_ELEMENT_AS_NULL' feature
> from true to false (see
> [here|[https://github.com/FasterXML/jackson-dataformat-xml/issues/411]]) and
> we can enable back this property using XMLMapper:
> {quote}xmlMapper.configure(FromXmlParser.Feature.EMPTY_ELEMENT_AS_NULL, true);
> {quote}
> However, there's no way to enable this behaviour in jaxonxml inside camel
> routes. In the
> [documentation|[https://camel.apache.org/components/3.14.x/dataformats/jacksonxml-dataformat.html#_enabling_or_disable_features_using_jackson],]
> It's specified that we can enable or disable certain types of properties
> that are inside SerializationFeature, DeserializationFeature and
> MapperFeature but there's no way to enable EMPTY_ELEMENT_AS_NULL since is in
> another enum (FromXmlParser). We've tried enabling the feature
> ACCEPT_EMPTY_STRING_AS_NULL_OBJECT but that doesn't work either.
> We've managed to implement a workaround by using instead of
> in our camel routes (we use Camel XML DSL), but that's not
> efficient as we would have to replace all references. So we need
> to have the possibility to enable back EMPTY_ELEMENT_AS_NULL from
> in camel XML DSL.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CAMEL-18347) camel-test-infra-kafka: instances are not properly singleton
Otavio Rodolfo Piske created CAMEL-18347: Summary: camel-test-infra-kafka: instances are not properly singleton Key: CAMEL-18347 URL: https://issues.apache.org/jira/browse/CAMEL-18347 Project: Camel Issue Type: Bug Components: camel-test-infra-kafka Affects Versions: 3.18.0, 3.19.0 Reporter: Otavio Rodolfo Piske Despite being advertised as singleton, the test infra still create multiple instances of the services. This can slow down test execution and use more resources than necessary. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-18345) EMPTY_ELEMENT_AS_NULL disabled by default in jackson-dataformat-xml
[
https://issues.apache.org/jira/browse/CAMEL-18345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-18345:
Issue Type: Improvement (was: Bug)
> EMPTY_ELEMENT_AS_NULL disabled by default in jackson-dataformat-xml
> ---
>
> Key: CAMEL-18345
> URL: https://issues.apache.org/jira/browse/CAMEL-18345
> Project: Camel
> Issue Type: Improvement
> Components: camel-jacksonxml
>Affects Versions: 3.3.0
>Reporter: José Bustamante
>Priority: Major
>
> Jackson 2.12.x changed the default for the 'EMPTY_ELEMENT_AS_NULL' feature
> from true to false (see
> [here|[https://github.com/FasterXML/jackson-dataformat-xml/issues/411]]) and
> we can enable back this property using XMLMapper:
> {quote}xmlMapper.configure(FromXmlParser.Feature.EMPTY_ELEMENT_AS_NULL, true);
> {quote}
> However, there's no way to enable this behaviour in jaxonxml inside camel
> routes. In the
> [documentation|[https://camel.apache.org/components/3.14.x/dataformats/jacksonxml-dataformat.html#_enabling_or_disable_features_using_jackson],]
> It's specified that we can enable or disable certain types of properties
> that are inside SerializationFeature, DeserializationFeature and
> MapperFeature but there's no way to enable EMPTY_ELEMENT_AS_NULL since is in
> another enum (FromXmlParser). We've tried enabling the feature
> ACCEPT_EMPTY_STRING_AS_NULL_OBJECT but that doesn't work either.
> We've managed to implement a workaround by using instead of
> in our camel routes (we use Camel XML DSL), but that's not
> efficient as we would have to replace all references. So we need
> to have the possibility to enable back EMPTY_ELEMENT_AS_NULL from
> in camel XML DSL.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CAMEL-18346) Remove use of Xalan
PJ Fanning created CAMEL-18346: -- Summary: Remove use of Xalan Key: CAMEL-18346 URL: https://issues.apache.org/jira/browse/CAMEL-18346 Project: Camel Issue Type: Improvement Reporter: PJ Fanning Xalan-J has an unfixed CVE. It is possible that this will be fixed in the future but Xalan-J has had only one release since 2008 (in 2014). https://www.cvedetails.com/cve/CVE-2022-34169/ Java has built-in support for TransformerFactory and XPathFactory. This means most apps that use Xalan-J can readily switch away. Saxon-HE is another well maintained alternative. One place where Camel still uses Xalan: https://github.com/apache/camel/blob/main/core/camel-core-engine/pom.xml#L325 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-18346) Remove use of Xalan
[ https://issues.apache.org/jira/browse/CAMEL-18346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-18346: Fix Version/s: 3.19.0 > Remove use of Xalan > --- > > Key: CAMEL-18346 > URL: https://issues.apache.org/jira/browse/CAMEL-18346 > Project: Camel > Issue Type: Task > Components: build system >Reporter: PJ Fanning >Priority: Minor > Fix For: 3.19.0 > > > Xalan-J has an unfixed CVE. It is possible that this will be fixed in the > future but Xalan-J has had only one release since 2008 (in 2014). > https://www.cvedetails.com/cve/CVE-2022-34169/ > Java has built-in support for TransformerFactory and XPathFactory. This means > most apps that use Xalan-J can readily switch away. Saxon-HE is another well > maintained alternative. > One place where Camel still uses Xalan: > https://github.com/apache/camel/blob/main/core/camel-core-engine/pom.xml#L325 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-18346) Remove use of Xalan
[ https://issues.apache.org/jira/browse/CAMEL-18346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17575128#comment-17575128 ] Claus Ibsen commented on CAMEL-18346: - You are welcome to send a PR that removes that profile > Remove use of Xalan > --- > > Key: CAMEL-18346 > URL: https://issues.apache.org/jira/browse/CAMEL-18346 > Project: Camel > Issue Type: Task > Components: build system >Reporter: PJ Fanning >Priority: Minor > > Xalan-J has an unfixed CVE. It is possible that this will be fixed in the > future but Xalan-J has had only one release since 2008 (in 2014). > https://www.cvedetails.com/cve/CVE-2022-34169/ > Java has built-in support for TransformerFactory and XPathFactory. This means > most apps that use Xalan-J can readily switch away. Saxon-HE is another well > maintained alternative. > One place where Camel still uses Xalan: > https://github.com/apache/camel/blob/main/core/camel-core-engine/pom.xml#L325 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-18346) Remove use of Xalan
[ https://issues.apache.org/jira/browse/CAMEL-18346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17575127#comment-17575127 ] Claus Ibsen commented on CAMEL-18346: - That is a profile that is never used, but allow to test with xalan. We test with woodstock by default as you can see further below. > Remove use of Xalan > --- > > Key: CAMEL-18346 > URL: https://issues.apache.org/jira/browse/CAMEL-18346 > Project: Camel > Issue Type: Improvement >Reporter: PJ Fanning >Priority: Major > > Xalan-J has an unfixed CVE. It is possible that this will be fixed in the > future but Xalan-J has had only one release since 2008 (in 2014). > https://www.cvedetails.com/cve/CVE-2022-34169/ > Java has built-in support for TransformerFactory and XPathFactory. This means > most apps that use Xalan-J can readily switch away. Saxon-HE is another well > maintained alternative. > One place where Camel still uses Xalan: > https://github.com/apache/camel/blob/main/core/camel-core-engine/pom.xml#L325 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-18346) Remove use of Xalan
[ https://issues.apache.org/jira/browse/CAMEL-18346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-18346: Issue Type: Task (was: Improvement) > Remove use of Xalan > --- > > Key: CAMEL-18346 > URL: https://issues.apache.org/jira/browse/CAMEL-18346 > Project: Camel > Issue Type: Task >Reporter: PJ Fanning >Priority: Major > > Xalan-J has an unfixed CVE. It is possible that this will be fixed in the > future but Xalan-J has had only one release since 2008 (in 2014). > https://www.cvedetails.com/cve/CVE-2022-34169/ > Java has built-in support for TransformerFactory and XPathFactory. This means > most apps that use Xalan-J can readily switch away. Saxon-HE is another well > maintained alternative. > One place where Camel still uses Xalan: > https://github.com/apache/camel/blob/main/core/camel-core-engine/pom.xml#L325 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-18346) Remove use of Xalan
[ https://issues.apache.org/jira/browse/CAMEL-18346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-18346: Priority: Minor (was: Major) > Remove use of Xalan > --- > > Key: CAMEL-18346 > URL: https://issues.apache.org/jira/browse/CAMEL-18346 > Project: Camel > Issue Type: Task >Reporter: PJ Fanning >Priority: Minor > > Xalan-J has an unfixed CVE. It is possible that this will be fixed in the > future but Xalan-J has had only one release since 2008 (in 2014). > https://www.cvedetails.com/cve/CVE-2022-34169/ > Java has built-in support for TransformerFactory and XPathFactory. This means > most apps that use Xalan-J can readily switch away. Saxon-HE is another well > maintained alternative. > One place where Camel still uses Xalan: > https://github.com/apache/camel/blob/main/core/camel-core-engine/pom.xml#L325 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-18346) Remove use of Xalan
[ https://issues.apache.org/jira/browse/CAMEL-18346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-18346: Component/s: build system > Remove use of Xalan > --- > > Key: CAMEL-18346 > URL: https://issues.apache.org/jira/browse/CAMEL-18346 > Project: Camel > Issue Type: Task > Components: build system >Reporter: PJ Fanning >Priority: Minor > > Xalan-J has an unfixed CVE. It is possible that this will be fixed in the > future but Xalan-J has had only one release since 2008 (in 2014). > https://www.cvedetails.com/cve/CVE-2022-34169/ > Java has built-in support for TransformerFactory and XPathFactory. This means > most apps that use Xalan-J can readily switch away. Saxon-HE is another well > maintained alternative. > One place where Camel still uses Xalan: > https://github.com/apache/camel/blob/main/core/camel-core-engine/pom.xml#L325 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-18345) EMPTY_ELEMENT_AS_NULL disabled by default in jackson-dataformat-xml
[
https://issues.apache.org/jira/browse/CAMEL-18345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17575125#comment-17575125
]
Claus Ibsen commented on CAMEL-18345:
-
You are using a very old Camel version. Try with latest release also.
> EMPTY_ELEMENT_AS_NULL disabled by default in jackson-dataformat-xml
> ---
>
> Key: CAMEL-18345
> URL: https://issues.apache.org/jira/browse/CAMEL-18345
> Project: Camel
> Issue Type: Improvement
> Components: camel-jacksonxml
>Affects Versions: 3.3.0
>Reporter: José Bustamante
>Priority: Major
>
> Jackson 2.12.x changed the default for the 'EMPTY_ELEMENT_AS_NULL' feature
> from true to false (see
> [here|[https://github.com/FasterXML/jackson-dataformat-xml/issues/411]]) and
> we can enable back this property using XMLMapper:
> {quote}xmlMapper.configure(FromXmlParser.Feature.EMPTY_ELEMENT_AS_NULL, true);
> {quote}
> However, there's no way to enable this behaviour in jaxonxml inside camel
> routes. In the
> [documentation|[https://camel.apache.org/components/3.14.x/dataformats/jacksonxml-dataformat.html#_enabling_or_disable_features_using_jackson],]
> It's specified that we can enable or disable certain types of properties
> that are inside SerializationFeature, DeserializationFeature and
> MapperFeature but there's no way to enable EMPTY_ELEMENT_AS_NULL since is in
> another enum (FromXmlParser). We've tried enabling the feature
> ACCEPT_EMPTY_STRING_AS_NULL_OBJECT but that doesn't work either.
> We've managed to implement a workaround by using instead of
> in our camel routes (we use Camel XML DSL), but that's not
> efficient as we would have to replace all references. So we need
> to have the possibility to enable back EMPTY_ELEMENT_AS_NULL from
> in camel XML DSL.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CAMEL-18345) EMPTY_ELEMENT_AS_NULL disabled by default in jackson-dataformat-xml
José Bustamante created CAMEL-18345:
---
Summary: EMPTY_ELEMENT_AS_NULL disabled by default in
jackson-dataformat-xml
Key: CAMEL-18345
URL: https://issues.apache.org/jira/browse/CAMEL-18345
Project: Camel
Issue Type: Bug
Components: camel-jacksonxml
Affects Versions: 3.3.0
Reporter: José Bustamante
Jackson 2.12.x changed the default for the 'EMPTY_ELEMENT_AS_NULL' feature from
true to false (see
[here|[https://github.com/FasterXML/jackson-dataformat-xml/issues/411]]) and we
can enable back this property using XMLMapper:
{quote}xmlMapper.configure(FromXmlParser.Feature.EMPTY_ELEMENT_AS_NULL, true);
{quote}
However, there's no way to enable this behaviour in jaxonxml inside camel
routes. In the
[documentation|[https://camel.apache.org/components/3.14.x/dataformats/jacksonxml-dataformat.html#_enabling_or_disable_features_using_jackson],]
It's specified that we can enable or disable certain types of properties that
are inside SerializationFeature, DeserializationFeature and MapperFeature but
there's no way to enable EMPTY_ELEMENT_AS_NULL since is in another enum
(FromXmlParser). We've tried enabling the feature
ACCEPT_EMPTY_STRING_AS_NULL_OBJECT but that doesn't work either.
We've managed to implement a workaround by using instead of
in our camel routes (we use Camel XML DSL), but that's not efficient as we
would have to replace all references. So we need to have the
possibility to enable back EMPTY_ELEMENT_AS_NULL from in camel XML
DSL.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CAMEL-18344) Supporting camel "camel-google-pubsub" and "camel-grpc" OSGi deployment
Denis Sergent created CAMEL-18344: - Summary: Supporting camel "camel-google-pubsub" and "camel-grpc" OSGi deployment Key: CAMEL-18344 URL: https://issues.apache.org/jira/browse/CAMEL-18344 Project: Camel Issue Type: Dependency upgrade Components: karaf Reporter: Denis Sergent There is no "camel-google-pubsub" and "camel-grpc" karaf features available anymore with Camel 3. It would be nice to have OSGi-ready features back for this version. cc [~xldai] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-18330) RouteTemplate: templateParameter not recognized
[
https://issues.apache.org/jira/browse/CAMEL-18330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-18330.
-
Fix Version/s: 3.19.0
Resolution: Cannot Reproduce
We may have fixed this with other changes
https://github.com/apache/camel/commit/a5be5fdce7309391ee9727af91e2ec3f55042790
> RouteTemplate: templateParameter not recognized
> ---
>
> Key: CAMEL-18330
> URL: https://issues.apache.org/jira/browse/CAMEL-18330
> Project: Camel
> Issue Type: Bug
>Affects Versions: 3.18.0
>Reporter: Raymond
>Priority: Minor
> Fix For: 3.19.0
>
>
> I'm not sure in how far this issue is related to
> (https://issues.apache.org/jira/browse/CAMEL-18328), but I report it anyway
> to be sure:
> I have to following template:
> {code:java}
> routeTemplate("myTemplate")
> .templateParameter("uri")
> .templateParameter("in")
> .templateParameter("out")
> .from("{{in}}")
> .to("{{uri}}")
> .to("{{out}}");{code}
> I can call this template with various uri's without issues. However when
> using a kamelet as uri templateparameter then after that it says it can find
> the out parameter (though it's in the creation of the template):
>
> {code:java}
>
> http://camel.apache.org/schema/spring;>
>
>
>
>
>
>
>
> {code}
> This is the stacktrace/error:
> {code:java}
> org.apache.camel.FailedToCreateRouteException: Failed to create route 105-3
> at: >>> To[{{out}}] <<< in route: Route(105-3)[From[{{in}}] -> [To[{{uri}}],
> To[{{out}}]]] because of Failed to resolve endpoint: {{out}} due to: Property
> with key [out] not found in properties from text: {{out}}
> at
> org.apache.camel.reifier.RouteReifier.doCreateRoute(RouteReifier.java:240)
> at
> org.apache.camel.reifier.RouteReifier.createRoute(RouteReifier.java:74)
> at
> org.apache.camel.impl.DefaultModelReifierFactory.createRoute(DefaultModelReifierFactory.java:49)
> at
> org.apache.camel.impl.DefaultCamelContext.startRouteDefinitions(DefaultCamelContext.java:862)
> at
> org.apache.camel.impl.DefaultModel.addRouteDefinitions(DefaultModel.java:188)
> at
> org.apache.camel.impl.DefaultModel.addRouteDefinition(DefaultModel.java:194)
> at
> org.apache.camel.impl.DefaultModel.addRouteFromTemplate(DefaultModel.java:418)
> at
> org.apache.camel.impl.DefaultModel.addRouteFromTemplatedRoute(DefaultModel.java:684)
> at
> org.apache.camel.impl.DefaultCamelContext.addRouteFromTemplatedRoute(DefaultCamelContext.java:466)
> at
> org.apache.camel.model.Model.addRouteFromTemplatedRoutes(Model.java:241)
> at
> org.apache.camel.builder.RouteBuilder.populateTemplatedRoutes(RouteBuilder.java:691)
> at
> org.apache.camel.builder.RouteBuilder.addRoutesToCamelContext(RouteBuilder.java:562)
> at
> org.apache.camel.impl.engine.AbstractCamelContext.addRoutes(AbstractCamelContext.java:1178)
> at org.apache.camel.spi.RoutesLoader.loadRoutes(RoutesLoader.java:80)
>
>
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CAMEL-18179) Supporting camel-jira OSGi deployment
[ https://issues.apache.org/jira/browse/CAMEL-18179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17575074#comment-17575074 ] Xilai Dai commented on CAMEL-18179: --- [~jbonofre], Any chance to backport the fixes into 3.18.x which is LTS version if I'm not wrong? > Supporting camel-jira OSGi deployment > - > > Key: CAMEL-18179 > URL: https://issues.apache.org/jira/browse/CAMEL-18179 > Project: Camel > Issue Type: Dependency upgrade > Components: karaf >Reporter: Xilai Dai >Assignee: Jean-Baptiste Onofré >Priority: Minor > Fix For: 3.19.0 > > > There is no "camel-jira" karaf feature available in Camel 3, e.g in the > https://repo1.maven.org/maven2/org/apache/camel/karaf/apache-camel/3.17.0/apache-camel-3.17.0-features.xml > for sure currently the libraries from com.atlassian.jira are not in the maven > central but under here http://packages.atlassian.com/maven-external/, > also the libraries are plain jar, NOT OSGi bundle, > But it would be good to the users if we can make camel-jira OSGi-ready. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (CAMEL-18329) RouteTemplate: templateParameter doesn't get resolved
[
https://issues.apache.org/jira/browse/CAMEL-18329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen reassigned CAMEL-18329:
---
Assignee: Claus Ibsen
> RouteTemplate: templateParameter doesn't get resolved
> -
>
> Key: CAMEL-18329
> URL: https://issues.apache.org/jira/browse/CAMEL-18329
> Project: Camel
> Issue Type: Bug
>Affects Versions: 3.18.0
>Reporter: Raymond
>Assignee: Claus Ibsen
>Priority: Minor
>
> I have a routetemplate:
> {code:java}
> routeTemplate("appendtobody")
> .templateParameter("append")
> .templateParameter("in")
> .templateParameter("out")
> .from("{{in}}")
> .transform(body().append("{{append}}"))
> .to("{{out}}");{code}
>
> I create the route from template like this:
> {code:java}
> http://camel.apache.org/schema/spring;>
>
>
>
>
>
> {code}
> I call it with a file that contains: "value" in the body.
> Expected output:
> {code:java}
> valueappendvalue
> {code}
> Actual output:
> {code:java}
> value{{append}}
> {code}
> Tested this scenario with 3.18.0 and 3.19.0-SNAPSHOT
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CAMEL-18179) Supporting camel-jira OSGi deployment
[ https://issues.apache.org/jira/browse/CAMEL-18179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17575078#comment-17575078 ] Jean-Baptiste Onofré commented on CAMEL-18179: -- [~xldai] sure, no problem, I will backport on 3.18.x. > Supporting camel-jira OSGi deployment > - > > Key: CAMEL-18179 > URL: https://issues.apache.org/jira/browse/CAMEL-18179 > Project: Camel > Issue Type: Dependency upgrade > Components: karaf >Reporter: Xilai Dai >Assignee: Jean-Baptiste Onofré >Priority: Minor > Fix For: 3.19.0 > > > There is no "camel-jira" karaf feature available in Camel 3, e.g in the > https://repo1.maven.org/maven2/org/apache/camel/karaf/apache-camel/3.17.0/apache-camel-3.17.0-features.xml > for sure currently the libraries from com.atlassian.jira are not in the maven > central but under here http://packages.atlassian.com/maven-external/, > also the libraries are plain jar, NOT OSGi bundle, > But it would be good to the users if we can make camel-jira OSGi-ready. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-18329) RouteTemplate: templateParameter doesn't get resolved
[
https://issues.apache.org/jira/browse/CAMEL-18329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17575077#comment-17575077
]
Claus Ibsen commented on CAMEL-18329:
-
See
https://github.com/apache/camel/commit/e127e287a7182b8ddbfc304a379ca0fae4554819
> RouteTemplate: templateParameter doesn't get resolved
> -
>
> Key: CAMEL-18329
> URL: https://issues.apache.org/jira/browse/CAMEL-18329
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 3.18.0
>Reporter: Raymond
>Assignee: Claus Ibsen
>Priority: Minor
> Fix For: 3.18.1, 3.19.0
>
>
> I have a routetemplate:
> {code:java}
> routeTemplate("appendtobody")
> .templateParameter("append")
> .templateParameter("in")
> .templateParameter("out")
> .from("{{in}}")
> .transform(body().append("{{append}}"))
> .to("{{out}}");{code}
>
> I create the route from template like this:
> {code:java}
> http://camel.apache.org/schema/spring;>
>
>
>
>
>
> {code}
> I call it with a file that contains: "value" in the body.
> Expected output:
> {code:java}
> valueappendvalue
> {code}
> Actual output:
> {code:java}
> value{{append}}
> {code}
> Tested this scenario with 3.18.0 and 3.19.0-SNAPSHOT
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (CAMEL-18329) RouteTemplate: templateParameter doesn't get resolved
[
https://issues.apache.org/jira/browse/CAMEL-18329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17575076#comment-17575076
]
Claus Ibsen edited comment on CAMEL-18329 at 8/4/22 7:18 AM:
-
You need to use an expression language to have it dynamic
{code}
.transform(simple("${body}{{append}}"))
{code}
The body().append(xxx) works as a constant value - it would also not replace in
regular Camel route (without route templates).
was (Author: davsclaus):
You need to use an expression language to have it dynamic
.transform(simple("${body}{{append}}"))
The body().append(xxx) works as a constant value - it would also not replace in
regular Camel route (without route templates).
> RouteTemplate: templateParameter doesn't get resolved
> -
>
> Key: CAMEL-18329
> URL: https://issues.apache.org/jira/browse/CAMEL-18329
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 3.18.0
>Reporter: Raymond
>Assignee: Claus Ibsen
>Priority: Minor
> Fix For: 3.18.1, 3.19.0
>
>
> I have a routetemplate:
> {code:java}
> routeTemplate("appendtobody")
> .templateParameter("append")
> .templateParameter("in")
> .templateParameter("out")
> .from("{{in}}")
> .transform(body().append("{{append}}"))
> .to("{{out}}");{code}
>
> I create the route from template like this:
> {code:java}
> http://camel.apache.org/schema/spring;>
>
>
>
>
>
> {code}
> I call it with a file that contains: "value" in the body.
> Expected output:
> {code:java}
> valueappendvalue
> {code}
> Actual output:
> {code:java}
> value{{append}}
> {code}
> Tested this scenario with 3.18.0 and 3.19.0-SNAPSHOT
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CAMEL-18329) RouteTemplate: templateParameter doesn't get resolved
[
https://issues.apache.org/jira/browse/CAMEL-18329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-18329.
-
Resolution: Not A Bug
> RouteTemplate: templateParameter doesn't get resolved
> -
>
> Key: CAMEL-18329
> URL: https://issues.apache.org/jira/browse/CAMEL-18329
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 3.18.0
>Reporter: Raymond
>Assignee: Claus Ibsen
>Priority: Minor
> Fix For: 3.18.1, 3.19.0
>
>
> I have a routetemplate:
> {code:java}
> routeTemplate("appendtobody")
> .templateParameter("append")
> .templateParameter("in")
> .templateParameter("out")
> .from("{{in}}")
> .transform(body().append("{{append}}"))
> .to("{{out}}");{code}
>
> I create the route from template like this:
> {code:java}
> http://camel.apache.org/schema/spring;>
>
>
>
>
>
> {code}
> I call it with a file that contains: "value" in the body.
> Expected output:
> {code:java}
> valueappendvalue
> {code}
> Actual output:
> {code:java}
> value{{append}}
> {code}
> Tested this scenario with 3.18.0 and 3.19.0-SNAPSHOT
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CAMEL-18329) RouteTemplate: templateParameter doesn't get resolved
[
https://issues.apache.org/jira/browse/CAMEL-18329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17575076#comment-17575076
]
Claus Ibsen commented on CAMEL-18329:
-
You need to use an expression language to have it dynamic
.transform(simple("${body}{{append}}"))
The body().append(xxx) works as a constant value - it would also not replace in
regular Camel route (without route templates).
> RouteTemplate: templateParameter doesn't get resolved
> -
>
> Key: CAMEL-18329
> URL: https://issues.apache.org/jira/browse/CAMEL-18329
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 3.18.0
>Reporter: Raymond
>Assignee: Claus Ibsen
>Priority: Minor
> Fix For: 3.18.1, 3.19.0
>
>
> I have a routetemplate:
> {code:java}
> routeTemplate("appendtobody")
> .templateParameter("append")
> .templateParameter("in")
> .templateParameter("out")
> .from("{{in}}")
> .transform(body().append("{{append}}"))
> .to("{{out}}");{code}
>
> I create the route from template like this:
> {code:java}
> http://camel.apache.org/schema/spring;>
>
>
>
>
>
> {code}
> I call it with a file that contains: "value" in the body.
> Expected output:
> {code:java}
> valueappendvalue
> {code}
> Actual output:
> {code:java}
> value{{append}}
> {code}
> Tested this scenario with 3.18.0 and 3.19.0-SNAPSHOT
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-18329) RouteTemplate: templateParameter doesn't get resolved
[
https://issues.apache.org/jira/browse/CAMEL-18329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-18329:
Component/s: camel-core
> RouteTemplate: templateParameter doesn't get resolved
> -
>
> Key: CAMEL-18329
> URL: https://issues.apache.org/jira/browse/CAMEL-18329
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 3.18.0
>Reporter: Raymond
>Assignee: Claus Ibsen
>Priority: Minor
> Fix For: 3.18.1, 3.19.0
>
>
> I have a routetemplate:
> {code:java}
> routeTemplate("appendtobody")
> .templateParameter("append")
> .templateParameter("in")
> .templateParameter("out")
> .from("{{in}}")
> .transform(body().append("{{append}}"))
> .to("{{out}}");{code}
>
> I create the route from template like this:
> {code:java}
> http://camel.apache.org/schema/spring;>
>
>
>
>
>
> {code}
> I call it with a file that contains: "value" in the body.
> Expected output:
> {code:java}
> valueappendvalue
> {code}
> Actual output:
> {code:java}
> value{{append}}
> {code}
> Tested this scenario with 3.18.0 and 3.19.0-SNAPSHOT
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-18329) RouteTemplate: templateParameter doesn't get resolved
[
https://issues.apache.org/jira/browse/CAMEL-18329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-18329:
Fix Version/s: 3.18.1
3.19.0
> RouteTemplate: templateParameter doesn't get resolved
> -
>
> Key: CAMEL-18329
> URL: https://issues.apache.org/jira/browse/CAMEL-18329
> Project: Camel
> Issue Type: Bug
>Affects Versions: 3.18.0
>Reporter: Raymond
>Assignee: Claus Ibsen
>Priority: Minor
> Fix For: 3.18.1, 3.19.0
>
>
> I have a routetemplate:
> {code:java}
> routeTemplate("appendtobody")
> .templateParameter("append")
> .templateParameter("in")
> .templateParameter("out")
> .from("{{in}}")
> .transform(body().append("{{append}}"))
> .to("{{out}}");{code}
>
> I create the route from template like this:
> {code:java}
> http://camel.apache.org/schema/spring;>
>
>
>
>
>
> {code}
> I call it with a file that contains: "value" in the body.
> Expected output:
> {code:java}
> valueappendvalue
> {code}
> Actual output:
> {code:java}
> value{{append}}
> {code}
> Tested this scenario with 3.18.0 and 3.19.0-SNAPSHOT
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-18327) camel-kafka: Kafka consumer closes when it is paused
[
https://issues.apache.org/jira/browse/CAMEL-18327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-18327:
Fix Version/s: 3.18.2
> camel-kafka: Kafka consumer closes when it is paused
>
>
> Key: CAMEL-18327
> URL: https://issues.apache.org/jira/browse/CAMEL-18327
> Project: Camel
> Issue Type: Task
> Components: camel-kafka
>Affects Versions: 3.17.0
>Reporter: rupam
>Assignee: Otavio Rodolfo Piske
>Priority: Major
> Fix For: 3.18.2, 3.19.0
>
>
>
> In the startPolling() method, if the consumer is suspending, then the
> unsubscribe method is called which permanently closes the consumer
>
> {code:java}
> Duration pollDuration = Duration.ofMillis(pollTimeoutMs);
> while (isKafkaConsumerRunnable() && isConnected() &&
> pollExceptionStrategy.canContinue()) {
> ConsumerRecords allRecords =
> consumer.poll(pollDuration);
> if (consumerListener != null) {
> if (!consumerListener.afterConsume(consumer)) {
> continue;
> }
> }
> ProcessingResult result =
> recordProcessorFacade.processPolledRecords(allRecords);
> if (result.isBreakOnErrorHit()) {
> LOG.debug("We hit an error ... setting flags to force reconnect");
> // force re-connect
> setReconnect(true);
> setConnected(false);
> }
> updateTaskState();
> }
> if (!isConnected()) {
> LOG.debug("Not reconnecting, check whether to auto-commit or not
> ...");
> commitManager.commit();
> }
> safeUnsubscribe();
> } catch (InterruptException e) {{code}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CAMEL-18327) camel-kafka: Kafka consumer closes when it is paused
[
https://issues.apache.org/jira/browse/CAMEL-18327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17575060#comment-17575060
]
Otavio Rodolfo Piske commented on CAMEL-18327:
--
c/c: [~davsclaus] let's keep this one open for now. There's still a few more
things to do (I removed it from the Fix Version 3.18.1 as I will need to
investigate more).
> camel-kafka: Kafka consumer closes when it is paused
>
>
> Key: CAMEL-18327
> URL: https://issues.apache.org/jira/browse/CAMEL-18327
> Project: Camel
> Issue Type: Task
> Components: camel-kafka
>Affects Versions: 3.17.0
>Reporter: rupam
>Assignee: Otavio Rodolfo Piske
>Priority: Major
> Fix For: 3.19.0
>
>
>
> In the startPolling() method, if the consumer is suspending, then the
> unsubscribe method is called which permanently closes the consumer
>
> {code:java}
> Duration pollDuration = Duration.ofMillis(pollTimeoutMs);
> while (isKafkaConsumerRunnable() && isConnected() &&
> pollExceptionStrategy.canContinue()) {
> ConsumerRecords allRecords =
> consumer.poll(pollDuration);
> if (consumerListener != null) {
> if (!consumerListener.afterConsume(consumer)) {
> continue;
> }
> }
> ProcessingResult result =
> recordProcessorFacade.processPolledRecords(allRecords);
> if (result.isBreakOnErrorHit()) {
> LOG.debug("We hit an error ... setting flags to force reconnect");
> // force re-connect
> setReconnect(true);
> setConnected(false);
> }
> updateTaskState();
> }
> if (!isConnected()) {
> LOG.debug("Not reconnecting, check whether to auto-commit or not
> ...");
> commitManager.commit();
> }
> safeUnsubscribe();
> } catch (InterruptException e) {{code}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-18327) camel-kafka: Kafka consumer closes when it is paused
[
https://issues.apache.org/jira/browse/CAMEL-18327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Otavio Rodolfo Piske updated CAMEL-18327:
-
Fix Version/s: (was: 3.18.1)
> camel-kafka: Kafka consumer closes when it is paused
>
>
> Key: CAMEL-18327
> URL: https://issues.apache.org/jira/browse/CAMEL-18327
> Project: Camel
> Issue Type: Task
> Components: camel-kafka
>Affects Versions: 3.17.0
>Reporter: rupam
>Assignee: Otavio Rodolfo Piske
>Priority: Major
> Fix For: 3.19.0
>
>
>
> In the startPolling() method, if the consumer is suspending, then the
> unsubscribe method is called which permanently closes the consumer
>
> {code:java}
> Duration pollDuration = Duration.ofMillis(pollTimeoutMs);
> while (isKafkaConsumerRunnable() && isConnected() &&
> pollExceptionStrategy.canContinue()) {
> ConsumerRecords allRecords =
> consumer.poll(pollDuration);
> if (consumerListener != null) {
> if (!consumerListener.afterConsume(consumer)) {
> continue;
> }
> }
> ProcessingResult result =
> recordProcessorFacade.processPolledRecords(allRecords);
> if (result.isBreakOnErrorHit()) {
> LOG.debug("We hit an error ... setting flags to force reconnect");
> // force re-connect
> setReconnect(true);
> setConnected(false);
> }
> updateTaskState();
> }
> if (!isConnected()) {
> LOG.debug("Not reconnecting, check whether to auto-commit or not
> ...");
> commitManager.commit();
> }
> safeUnsubscribe();
> } catch (InterruptException e) {{code}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CAMEL-18327) camel-kafka: Kafka consumer closes when it is paused
[
https://issues.apache.org/jira/browse/CAMEL-18327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17575058#comment-17575058
]
Otavio Rodolfo Piske commented on CAMEL-18327:
--
Upon closer inspection: we cannot simply remove that one without side effects.
It breaks quite a good number of test cases.
So, let's keep that one in and let's keep this ticket open for now. I'll have
to investigate more carefully about the proper way to handle this.
> camel-kafka: Kafka consumer closes when it is paused
>
>
> Key: CAMEL-18327
> URL: https://issues.apache.org/jira/browse/CAMEL-18327
> Project: Camel
> Issue Type: Task
> Components: camel-kafka
>Affects Versions: 3.17.0
>Reporter: rupam
>Assignee: Otavio Rodolfo Piske
>Priority: Major
> Fix For: 3.18.1, 3.19.0
>
>
>
> In the startPolling() method, if the consumer is suspending, then the
> unsubscribe method is called which permanently closes the consumer
>
> {code:java}
> Duration pollDuration = Duration.ofMillis(pollTimeoutMs);
> while (isKafkaConsumerRunnable() && isConnected() &&
> pollExceptionStrategy.canContinue()) {
> ConsumerRecords allRecords =
> consumer.poll(pollDuration);
> if (consumerListener != null) {
> if (!consumerListener.afterConsume(consumer)) {
> continue;
> }
> }
> ProcessingResult result =
> recordProcessorFacade.processPolledRecords(allRecords);
> if (result.isBreakOnErrorHit()) {
> LOG.debug("We hit an error ... setting flags to force reconnect");
> // force re-connect
> setReconnect(true);
> setConnected(false);
> }
> updateTaskState();
> }
> if (!isConnected()) {
> LOG.debug("Not reconnecting, check whether to auto-commit or not
> ...");
> commitManager.commit();
> }
> safeUnsubscribe();
> } catch (InterruptException e) {{code}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CAMEL-18327) camel-kafka: Kafka consumer closes when it is paused
[
https://issues.apache.org/jira/browse/CAMEL-18327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17575040#comment-17575040
]
Otavio Rodolfo Piske commented on CAMEL-18327:
--
Indeed. I think that one can be removed too. I'll send a PR soon.
> camel-kafka: Kafka consumer closes when it is paused
>
>
> Key: CAMEL-18327
> URL: https://issues.apache.org/jira/browse/CAMEL-18327
> Project: Camel
> Issue Type: Task
> Components: camel-kafka
>Affects Versions: 3.17.0
>Reporter: rupam
>Assignee: Otavio Rodolfo Piske
>Priority: Major
> Fix For: 3.18.1, 3.19.0
>
>
>
> In the startPolling() method, if the consumer is suspending, then the
> unsubscribe method is called which permanently closes the consumer
>
> {code:java}
> Duration pollDuration = Duration.ofMillis(pollTimeoutMs);
> while (isKafkaConsumerRunnable() && isConnected() &&
> pollExceptionStrategy.canContinue()) {
> ConsumerRecords allRecords =
> consumer.poll(pollDuration);
> if (consumerListener != null) {
> if (!consumerListener.afterConsume(consumer)) {
> continue;
> }
> }
> ProcessingResult result =
> recordProcessorFacade.processPolledRecords(allRecords);
> if (result.isBreakOnErrorHit()) {
> LOG.debug("We hit an error ... setting flags to force reconnect");
> // force re-connect
> setReconnect(true);
> setConnected(false);
> }
> updateTaskState();
> }
> if (!isConnected()) {
> LOG.debug("Not reconnecting, check whether to auto-commit or not
> ...");
> commitManager.commit();
> }
> safeUnsubscribe();
> } catch (InterruptException e) {{code}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
