[jira] [Created] (CAMEL-18460) Duplicate dependency in camel-spring-boot-bom
Jakob Thun created CAMEL-18460: -- Summary: Duplicate dependency in camel-spring-boot-bom Key: CAMEL-18460 URL: https://issues.apache.org/jira/browse/CAMEL-18460 Project: Camel Issue Type: Bug Affects Versions: 3.18.1, 3.18.0 Reporter: Jakob Thun Attachments: image-2022-09-03-04-13-20-489.png I found a duplicate dependency in the camel-spring-boot project. More spficically in the tooling/camel-spring-boot-bom Not sure if there can be any reason for having that twice. !image-2022-09-03-04-13-20-489.png|width=599,height=222! It seems to have been that way since modeline was added (3.18.0 and 3.18.1 have the same duplicate declaration). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-18459) Set application properties in messages sent to Azure Service Bus
[ https://issues.apache.org/jira/browse/CAMEL-18459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17599752#comment-17599752 ] Dylan Piergies commented on CAMEL-18459: Created pull request for this issue: https://github.com/apache/camel/pull/8269 > Set application properties in messages sent to Azure Service Bus > > > Key: CAMEL-18459 > URL: https://issues.apache.org/jira/browse/CAMEL-18459 > Project: Camel > Issue Type: New Feature > Components: camel-azure >Reporter: Dylan Piergies >Priority: Major > > It is currently not possible to have the Azure Service Bus producer set > application properties (also known as custom properties) in messages sent to > Azure Service Bus. > The need to enable these properties to be set arises because these properties > can be used in filter rules used in topic/queue subscriptions. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] (CAMEL-18459) Set application properties in messages sent to Azure Service Bus
[ https://issues.apache.org/jira/browse/CAMEL-18459 ] Dylan Piergies deleted comment on CAMEL-18459: was (Author: dylan.piergies): Created pull request for this issue: https://github.com/apache/camel/pull/8269 > Set application properties in messages sent to Azure Service Bus > > > Key: CAMEL-18459 > URL: https://issues.apache.org/jira/browse/CAMEL-18459 > Project: Camel > Issue Type: New Feature > Components: camel-azure >Reporter: Dylan Piergies >Priority: Major > > It is currently not possible to have the Azure Service Bus producer set > application properties (also known as custom properties) in messages sent to > Azure Service Bus. > The need to enable these properties to be set arises because these properties > can be used in filter rules used in topic/queue subscriptions. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-18459) Set application properties in messages sent to Azure Service Bus
Dylan Piergies created CAMEL-18459: -- Summary: Set application properties in messages sent to Azure Service Bus Key: CAMEL-18459 URL: https://issues.apache.org/jira/browse/CAMEL-18459 Project: Camel Issue Type: New Feature Components: camel-azure Reporter: Dylan Piergies It is currently not possible to have the Azure Service Bus producer set application properties (also known as custom properties) in messages sent to Azure Service Bus. The need to enable these properties to be set arises because these properties can be used in filter rules used in topic/queue subscriptions. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-16592) camel-core - HasCamelContext use it more
[ https://issues.apache.org/jira/browse/CAMEL-16592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-16592: Fix Version/s: 4.0 (was: 3.x) > camel-core - HasCamelContext use it more > > > Key: CAMEL-16592 > URL: https://issues.apache.org/jira/browse/CAMEL-16592 > Project: Camel > Issue Type: Improvement > Components: camel-core >Reporter: Claus Ibsen >Priority: Major > Fix For: 4.0 > > > This API was recently ported over from camel-k. Its not much in use, but we > could start to markup more that has a camel context. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-16578) Implement or remove MLLP component LogPhi functionality
[ https://issues.apache.org/jira/browse/CAMEL-16578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-16578: Fix Version/s: 3.19.0 > Implement or remove MLLP component LogPhi functionality > --- > > Key: CAMEL-16578 > URL: https://issues.apache.org/jira/browse/CAMEL-16578 > Project: Camel > Issue Type: Improvement > Components: camel-mllp >Reporter: James Netherton >Priority: Minor > Fix For: 3.19.0 > > > MLLP has a component configuration option 'logPhi'. From what I can tell, it > does nothing. The value is never read wherever the PHI is used in log > messages / exceptions etc. The functionality should either be implemented or > removed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-16578) Implement or remove MLLP component LogPhi functionality
[ https://issues.apache.org/jira/browse/CAMEL-16578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17599662#comment-17599662 ] Claus Ibsen commented on CAMEL-16578: - Lets remove this > Implement or remove MLLP component LogPhi functionality > --- > > Key: CAMEL-16578 > URL: https://issues.apache.org/jira/browse/CAMEL-16578 > Project: Camel > Issue Type: Improvement > Components: camel-mllp >Reporter: James Netherton >Priority: Minor > > MLLP has a component configuration option 'logPhi'. From what I can tell, it > does nothing. The value is never read wherever the PHI is used in log > messages / exceptions etc. The functionality should either be implemented or > removed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-16579) Avoid static configuration variables in MllpComponent
[ https://issues.apache.org/jira/browse/CAMEL-16579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-16579. - Resolution: Won't Fix we move to spring boot / quarkus style where you are not in app servers > Avoid static configuration variables in MllpComponent > - > > Key: CAMEL-16579 > URL: https://issues.apache.org/jira/browse/CAMEL-16579 > Project: Camel > Issue Type: Improvement >Reporter: James Netherton >Priority: Minor > > MllpComponent has some static variables for options logPhi, logPhiMaxBytes & > defaultCharset. I think the original intent is that they are set up via > system properties. But statics do not play well in some environments (E.g > WildFly) where the component class is shared among all applications deployed > into the container. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-16578) Implement or remove MLLP component LogPhi functionality
[ https://issues.apache.org/jira/browse/CAMEL-16578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17599663#comment-17599663 ] Claus Ibsen commented on CAMEL-16578: - Lets remove this > Implement or remove MLLP component LogPhi functionality > --- > > Key: CAMEL-16578 > URL: https://issues.apache.org/jira/browse/CAMEL-16578 > Project: Camel > Issue Type: Improvement > Components: camel-mllp >Reporter: James Netherton >Priority: Minor > > MLLP has a component configuration option 'logPhi'. From what I can tell, it > does nothing. The value is never read wherever the PHI is used in log > messages / exceptions etc. The functionality should either be implemented or > removed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-16501) camel-jpa - Avoid using EntityManager from header by default
[ https://issues.apache.org/jira/browse/CAMEL-16501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-16501: Priority: Minor (was: Major) > camel-jpa - Avoid using EntityManager from header by default > > > Key: CAMEL-16501 > URL: https://issues.apache.org/jira/browse/CAMEL-16501 > Project: Camel > Issue Type: Improvement > Components: camel-jpa >Reporter: Claus Ibsen >Priority: Minor > Fix For: 3.x > > > See CAMEL-16470 > Historically camel-jpa would lookup from exchange header / property an > EntityManager to use instead of from its own component. This was needed by > jbpm and other 3rd party frameworks that integrated with Camel. > However this causes pain for normal users, where you just want to use the jpa > component out of the box with the JPA EM it has been configured with. And if > you add other jpa components to integrate with other databases, then they > should out of the box use their own EM and so on. This is how JMS, Kafka and > other components work. > So to allow the old behavior, we add a boolean option on the jpa component to > turn on the old style. And then leave it off for new style onwards. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-16564) camel-blueprint-spring - A new module to load Spring XML with Camel in OSGi
[
https://issues.apache.org/jira/browse/CAMEL-16564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-16564.
-
Resolution: Won't Fix
> camel-blueprint-spring - A new module to load Spring XML with Camel in OSGi
> ---
>
> Key: CAMEL-16564
> URL: https://issues.apache.org/jira/browse/CAMEL-16564
> Project: Camel
> Issue Type: New Feature
> Components: karaf, osgi
>Affects Versions: 3.9.0
>Reporter: Piotr Klimczak
>Assignee: Jean-Baptiste Onofré
>Priority: Minor
> Fix For: 3.x
>
>
> Camel Blueprint namespace handler is missing Spring Namespace declaration:
> {code:java}
> http://www.osgi.org/xmlns/blueprint/v1.0.0;>
>
>
>
>
> http://camel.apache.org/schema/spring
> http://camel.apache.org/schema/blueprint
> http://camel.apache.org/schema/placeholder
>
>
>
> class="org.apache.camel.blueprint.handler.CamelNamespaceHandler"/>
>
> {code}
> There is support implemented in Camel Blueprint project (partially), there is
> even some test spring context, but no real test coverage for this.
> Is it because Apache Camel community is abandoning such approach?
> We have quite few integrations which we have to be able to run in both:
> Tomcat and Karaf.
> I can provide some patches and improvements, provided that the community is
> interested in supporting such path, rather then me spending time and nobody
> even accepting PRs.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CAMEL-16488) Investigate test speed up for camel-ftp
[ https://issues.apache.org/jira/browse/CAMEL-16488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17599660#comment-17599660 ] Claus Ibsen commented on CAMEL-16488: - Did we not speedup ftp tests already? > Investigate test speed up for camel-ftp > --- > > Key: CAMEL-16488 > URL: https://issues.apache.org/jira/browse/CAMEL-16488 > Project: Camel > Issue Type: Task > Components: camel-ftp, tests >Reporter: Otavio Rodolfo Piske >Assignee: Otavio Rodolfo Piske >Priority: Major > > Check if we can reduce test duration for camel-ftp by moving some of the > tests to JUnit 5 nested classes. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-16485) Allow XML namespaces for xpath mock expectations
[
https://issues.apache.org/jira/browse/CAMEL-16485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-16485.
-
Resolution: Information Provided
> Allow XML namespaces for xpath mock expectations
>
>
> Key: CAMEL-16485
> URL: https://issues.apache.org/jira/browse/CAMEL-16485
> Project: Camel
> Issue Type: Improvement
> Components: camel-test
>Affects Versions: 3.9.0
>Reporter: Dietrich Schulten
>Priority: Major
>
> It is possible to write an xpath expectation for a mock endpoint:
> {code:java}
> mockendpoint.message(0).body().matches().xpath("/ns2:myElement"){code}
> However, this does not seem to work with namespaced elements (ns2 in the
> example above).
> The Camel XPath documentation says that the {{Namespaces}} class can be used
> to define namespaces for e.g. xpath filters (btw. the code snippet that was
> formerly presented to show the usage got lost in the current manual).
> Also, the {{XPathBuilder}} already has a {{namespace()}} method to set
> namespaces. But it appears that the {{MockExpressionClause.getExpressionValue
> }}does not support that, it uses {{XPathLanguage.createPredicate}} to create
> the XPath expression with a plain {{XPathBuilder}} without defining
> namespaces.
> Is it possible to add namespaces to mock expectations somehow? If not I would
> like to suggest such support as an improvement. If it were built like the
> filter DSL, it should be possible to say sth like:
> {code:java}
> Namespaces namespaces = new Namespaces("ns2", "http://xpsw.domap.de/xpsw174;);
> mockendpoint.message(0).body().matches().xpath("/ns2:myElement", namespaces)
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CAMEL-16487) camel-request-reply - Component for request reply using in-memory queue
[ https://issues.apache.org/jira/browse/CAMEL-16487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-16487. - Resolution: Won't Fix > camel-request-reply - Component for request reply using in-memory queue > --- > > Key: CAMEL-16487 > URL: https://issues.apache.org/jira/browse/CAMEL-16487 > Project: Camel > Issue Type: New Feature > Components: camel-core >Reporter: Claus Ibsen >Priority: Major > Fix For: 3.x > > > We can either improve the seda component to have an correlation map with > timeout and the likes (eg like camel-jms have). > But this component current behavior has been as it has been since Camel 1, > where the requestor will wait for the reply. > What we need is an async correlation manager (like camel-jms). > So either we > - change the SEDA implementation > - add a new component > In the old days with JBI there was the camel-nmr component that has this > strategy, but it was replaced with JMS as the solution as you have all of > this out of box with JMS, and it came out of the box with ServiceMix -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-16484) Camel-Dropbox: Bump to Dropbox-core 5.x
[ https://issues.apache.org/jira/browse/CAMEL-16484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17599658#comment-17599658 ] Claus Ibsen commented on CAMEL-16484: - Any update on this > Camel-Dropbox: Bump to Dropbox-core 5.x > --- > > Key: CAMEL-16484 > URL: https://issues.apache.org/jira/browse/CAMEL-16484 > Project: Camel > Issue Type: Dependency upgrade > Components: camel-dropbox >Reporter: Andrea Cosentino >Assignee: Andrea Cosentino >Priority: Major > Fix For: 3.x > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-16483) Camel-Nats: Supports jetstream API
[ https://issues.apache.org/jira/browse/CAMEL-16483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-16483: Priority: Minor (was: Major) > Camel-Nats: Supports jetstream API > -- > > Key: CAMEL-16483 > URL: https://issues.apache.org/jira/browse/CAMEL-16483 > Project: Camel > Issue Type: New Feature > Components: camel-nats >Reporter: Andrea Cosentino >Priority: Minor > Fix For: 3.x > > > [https://docs.nats.io/jetstream/jetstream] > > https://github.com/nats-io/nats.java#jetstream -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-16483) Camel-Nats: Supports jetstream API
[ https://issues.apache.org/jira/browse/CAMEL-16483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17599657#comment-17599657 ] Claus Ibsen commented on CAMEL-16483: - Yes a new component is welcome if anyone is able to work on this > Camel-Nats: Supports jetstream API > -- > > Key: CAMEL-16483 > URL: https://issues.apache.org/jira/browse/CAMEL-16483 > Project: Camel > Issue Type: New Feature > Components: camel-nats >Reporter: Andrea Cosentino >Priority: Major > Fix For: 3.x > > > [https://docs.nats.io/jetstream/jetstream] > > https://github.com/nats-io/nats.java#jetstream -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-16452) camel-core - Optimized ThreadPool with reusable tasks
[ https://issues.apache.org/jira/browse/CAMEL-16452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-16452: Priority: Minor (was: Major) > camel-core - Optimized ThreadPool with reusable tasks > - > > Key: CAMEL-16452 > URL: https://issues.apache.org/jira/browse/CAMEL-16452 > Project: Camel > Issue Type: Improvement > Components: camel-core >Reporter: Claus Ibsen >Priority: Minor > > Camel has been optimized so much that profiling now reveals that when using > JDKs thread pool then every time a a task is submitted then a FutureTask is > created which then costs object allocations. > We can look at having a PooledFutureTask where you can execute runAndReset > instead. However this prevents using future get to get a result. But in some > use-cases we do not use this, such as WireTap EIP and (and maybe some other > EIPs) > java.util.concurrent.FutureTask#runAndReset -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-18458) camel-core - Remove eager loading classes
Claus Ibsen created CAMEL-18458: --- Summary: camel-core - Remove eager loading classes Key: CAMEL-18458 URL: https://issues.apache.org/jira/browse/CAMEL-18458 Project: Camel Issue Type: Improvement Components: camel-core Reporter: Claus Ibsen Assignee: Claus Ibsen Fix For: 3.19.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-16446) camel-core - Optimize EIPs to eager load needed classes
[ https://issues.apache.org/jira/browse/CAMEL-16446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-16446. - Resolution: Won't Fix > camel-core - Optimize EIPs to eager load needed classes > --- > > Key: CAMEL-16446 > URL: https://issues.apache.org/jira/browse/CAMEL-16446 > Project: Camel > Issue Type: Improvement > Components: camel-core >Reporter: Claus Ibsen >Priority: Minor > Fix For: 3.x > > > In doBuild we should eager force loading needed classes, as otherwise they > are loaded on 1st message processed, which has a little overhead on > processing this message. > Also if doing eager loading in doBuild we can leverage graalvm architectures > to quickly startup -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-16435) camel-huaweicloud - SMN component-support custom service endpoint
[ https://issues.apache.org/jira/browse/CAMEL-16435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-16435: Summary: camel-huaweicloud - SMN component-support custom service endpoint (was: SMN component-support custom service endpoint) > camel-huaweicloud - SMN component-support custom service endpoint > -- > > Key: CAMEL-16435 > URL: https://issues.apache.org/jira/browse/CAMEL-16435 > Project: Camel > Issue Type: Improvement >Affects Versions: 3.8.0, 3.9.0 >Reporter: lyndonmiao >Priority: Minor > Labels: SMN > Original Estimate: 168h > Remaining Estimate: 168h > > In current SMN component, we get endpoint of the service using the > SmnRegion.valueOf(region).getEndpoint() method in huaweicloud-sdk-smn-3.0.32, > while the SmnRegion.valueOf() method restricts the region to Huawei Public > Cloud regions. In some situation, sunch as Huwei Private Cloud, the regions > are differernt from those in Public Cloud, and we cannot use the method > anymore, so we need to customize the endpoint address. > We can add a new parameter In SMN component , which can enable users to use a > custom SMN endpoint. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-16435) SMN component-support custom service endpoint
[ https://issues.apache.org/jira/browse/CAMEL-16435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-16435: Priority: Minor (was: Major) > SMN component-support custom service endpoint > - > > Key: CAMEL-16435 > URL: https://issues.apache.org/jira/browse/CAMEL-16435 > Project: Camel > Issue Type: Improvement >Affects Versions: 3.8.0, 3.9.0 >Reporter: lyndonmiao >Priority: Minor > Labels: SMN > Original Estimate: 168h > Remaining Estimate: 168h > > In current SMN component, we get endpoint of the service using the > SmnRegion.valueOf(region).getEndpoint() method in huaweicloud-sdk-smn-3.0.32, > while the SmnRegion.valueOf() method restricts the region to Huawei Public > Cloud regions. In some situation, sunch as Huwei Private Cloud, the regions > are differernt from those in Public Cloud, and we cannot use the method > anymore, so we need to customize the endpoint address. > We can add a new parameter In SMN component , which can enable users to use a > custom SMN endpoint. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-16415) camel-infinispan: investigate integration tests on OSX
[ https://issues.apache.org/jira/browse/CAMEL-16415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-16415. - Resolution: Cannot Reproduce > camel-infinispan: investigate integration tests on OSX > -- > > Key: CAMEL-16415 > URL: https://issues.apache.org/jira/browse/CAMEL-16415 > Project: Camel > Issue Type: Task >Reporter: Guillaume Nodet >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-16411) camel-infinispan: tests hang on OSX
[ https://issues.apache.org/jira/browse/CAMEL-16411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-16411. - Resolution: Cannot Reproduce > camel-infinispan: tests hang on OSX > --- > > Key: CAMEL-16411 > URL: https://issues.apache.org/jira/browse/CAMEL-16411 > Project: Camel > Issue Type: Task >Reporter: Guillaume Nodet >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-16386) camel-rsocket - Add a new Camel component for RSocket
[ https://issues.apache.org/jira/browse/CAMEL-16386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-16386. - Resolution: Won't Fix > camel-rsocket - Add a new Camel component for RSocket > - > > Key: CAMEL-16386 > URL: https://issues.apache.org/jira/browse/CAMEL-16386 > Project: Camel > Issue Type: New Feature >Reporter: Nikola Micić >Priority: Major > Fix For: 3.x > > > I would like to propose a new component for RSocket. > The idea is to implement it in a similar way like already existing components > for HTTP and WebSocket. Currently RSocket in Java is implemented using Netty > via TCP and WebSocket protocols. Apache Camel already has component for Netty > which is also a good example from using as a model. > Uri of the new component could be like: > * rsocket:tcp://host:port? > * rsocket:websocket://host:port?. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-16360) Add Pulsar Support for Scheduled/Delayed MEssages
[ https://issues.apache.org/jira/browse/CAMEL-16360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17599656#comment-17599656 ] Claus Ibsen commented on CAMEL-16360: - Any update on this? > Add Pulsar Support for Scheduled/Delayed MEssages > - > > Key: CAMEL-16360 > URL: https://issues.apache.org/jira/browse/CAMEL-16360 > Project: Camel > Issue Type: New Feature > Components: camel-pulsar >Reporter: obby >Priority: Minor > > Pulsar supports delayed/scheduled messages as stated here > [delayed-message-delivery|https://pulsar.apache.org/blog/2019/07/05/Apache-Pulsar-2-4-0/#delayed-message-delivery]. > can this be added as this has been in place from pulsar version 2.4.0. I > would be willing to implement it. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-16360) Add Pulsar Support for Scheduled/Delayed MEssages
[ https://issues.apache.org/jira/browse/CAMEL-16360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-16360: Priority: Minor (was: Major) > Add Pulsar Support for Scheduled/Delayed MEssages > - > > Key: CAMEL-16360 > URL: https://issues.apache.org/jira/browse/CAMEL-16360 > Project: Camel > Issue Type: New Feature > Components: camel-pulsar >Reporter: obby >Priority: Minor > > Pulsar supports delayed/scheduled messages as stated here > [delayed-message-delivery|https://pulsar.apache.org/blog/2019/07/05/Apache-Pulsar-2-4-0/#delayed-message-delivery]. > can this be added as this has been in place from pulsar version 2.4.0. I > would be willing to implement it. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-16320) Netty-http should support redirects
[
https://issues.apache.org/jira/browse/CAMEL-16320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-16320.
-
Resolution: Won't Fix
use vertx-http instead of some better http component
> Netty-http should support redirects
> ---
>
> Key: CAMEL-16320
> URL: https://issues.apache.org/jira/browse/CAMEL-16320
> Project: Camel
> Issue Type: Improvement
> Components: camel-netty-http
>Reporter: Nicola Ferraro
>Priority: Major
> Fix For: 3.x
>
>
> I'm running the following integration:
>
> {code:java}
> - from:
> uri: "timer:yaml"
> parameters:
> period: "1"
> steps:
> - to:
> "netty-http:https://github.com/apache/camel/raw/7204aa132662ab6cb8e3c5afea8b9b0859eff0e8/docs/img/logo.png;
> - to: "log:info"
> {code}
> With `kamel local run netty.yaml`.
> It hits a redirect on Github, but there's no way to "follow redirects" in the
> component documentation, like for the "http" component.
> Error:
>
> {code:java}
> 2021-03-09 14:58:45,031 WARN [org.apa.cam.com.tim.TimerConsumer] (Camel
> Thread #1 - NettyClientTCPWorker) Error processing exchange.
> Exchange[1AC7E2A0D31F4A0-]. Caused by:
> [org.apache.camel.component.netty.http.NettyHttpOperationFailedException -
> Netty HTTP operation failed invoking null with statusCode: 302,
> redirectLocation:
> https://raw.githubusercontent.com/apache/camel/7204aa132662ab6cb8e3c5afea8b9b0859eff0e8/docs/img/logo.png]:
> org.apache.camel.component.netty.http.NettyHttpOperationFailedException:
> Netty HTTP operation failed invoking null with statusCode: 302,
> redirectLocation:
> https://raw.githubusercontent.com/apache/camel/7204aa132662ab6cb8e3c5afea8b9b0859eff0e8/docs/img/logo.png
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-16352) Generate JARS without OSGi metadata
[ https://issues.apache.org/jira/browse/CAMEL-16352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-16352: Component/s: build system > Generate JARS without OSGi metadata > --- > > Key: CAMEL-16352 > URL: https://issues.apache.org/jira/browse/CAMEL-16352 > Project: Camel > Issue Type: Improvement > Components: build system >Reporter: Claus Ibsen >Priority: Major > Fix For: 4.0 > > > Just a ticket to remind that if we get camel-karaf to provide all JARs for > OSGi and with OSGi metadata in their MANIFEST.MF entires. > Then we can remove this from core Camel and that actually leads to reduce > memory footprint. As the OSGi manifest is very verbose and takes up memory > that is not for any good for non OSGi users. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-16352) Generate JARS without OSGi metadata
[ https://issues.apache.org/jira/browse/CAMEL-16352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-16352: Fix Version/s: 4.0 (was: Future) > Generate JARS without OSGi metadata > --- > > Key: CAMEL-16352 > URL: https://issues.apache.org/jira/browse/CAMEL-16352 > Project: Camel > Issue Type: Improvement >Reporter: Claus Ibsen >Priority: Major > Fix For: 4.0 > > > Just a ticket to remind that if we get camel-karaf to provide all JARs for > OSGi and with OSGi metadata in their MANIFEST.MF entires. > Then we can remove this from core Camel and that actually leads to reduce > memory footprint. As the OSGi manifest is very verbose and takes up memory > that is not for any good for non OSGi users. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-16304) Provide a camel-jctools component
[ https://issues.apache.org/jira/browse/CAMEL-16304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-16304. - Resolution: Abandoned > Provide a camel-jctools component > - > > Key: CAMEL-16304 > URL: https://issues.apache.org/jira/browse/CAMEL-16304 > Project: Camel > Issue Type: New Feature >Reporter: Luca Burgazzoli >Priority: Minor > Fix For: 3.x > > > We should think about providing a seda like component based on > [JCTools|https://github.com/JCTools/JCTools] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-16289) camel-tracing - Add vertx-kafka as decorator
[ https://issues.apache.org/jira/browse/CAMEL-16289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-16289. - Resolution: Won't Fix vertx-kafka is deprecated > camel-tracing - Add vertx-kafka as decorator > > > Key: CAMEL-16289 > URL: https://issues.apache.org/jira/browse/CAMEL-16289 > Project: Camel > Issue Type: Improvement >Reporter: Claus Ibsen >Priority: Major > Fix For: 3.x > > > The camel-tracing module has decorators. One for kafka, but we need one for > vertx-kafka. > They may have the same header keys so its mostly a copy/paste. But check with > the source code what the keys are named in camel-vertx-kafka. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-16248) Camel Catalog validation is reporting a false positive for specific properties of dataformats
[
https://issues.apache.org/jira/browse/CAMEL-16248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-16248.
-
Resolution: Information Provided
> Camel Catalog validation is reporting a false positive for specific
> properties of dataformats
> -
>
> Key: CAMEL-16248
> URL: https://issues.apache.org/jira/browse/CAMEL-16248
> Project: Camel
> Issue Type: Improvement
> Components: tooling
>Affects Versions: 3.8.0
>Reporter: Aurélien Pupier
>Priority: Minor
>
> {noformat}
> camel.dataformat.fhirJson.enabled
> {noformat}
> is reporting an unknown property validation error although it is a valid
> setting.
> See
> https://github.com/apache/camel-kafka-connector-examples/issues/292#issuecomment-784018926
> Should it be added to the catalog? Or shoudl it be fixed in the validation
> algorithm?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CAMEL-16249) Camel Catalog validation reports fals epositive for Camel Docker specific headers
[
https://issues.apache.org/jira/browse/CAMEL-16249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-16249.
-
Resolution: Information Provided
> Camel Catalog validation reports fals epositive for Camel Docker specific
> headers
> -
>
> Key: CAMEL-16249
> URL: https://issues.apache.org/jira/browse/CAMEL-16249
> Project: Camel
> Issue Type: Improvement
> Components: tooling
>Affects Versions: 3.8.0
>Reporter: Aurélien Pupier
>Priority: Minor
>
> {noformat}
> camel.sink.endpoint.tag=latest
> {noformat}
> or
> {noformat}
> camel.source.endpoint.containerId=
> {noformat}
> reports unknown property valdiation error although they are valid
> see
> https://github.com/apache/camel-kafka-connector-examples/issues/293#issuecomment-784022194
> Should it be somethign to add in Catalog? or need to fiw the valdiation
> algorithm?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CAMEL-16269) camel-http - Optimize its protocol header filter strategy
[ https://issues.apache.org/jira/browse/CAMEL-16269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-16269. - Resolution: Won't Fix > camel-http - Optimize its protocol header filter strategy > - > > Key: CAMEL-16269 > URL: https://issues.apache.org/jira/browse/CAMEL-16269 > Project: Camel > Issue Type: Improvement > Components: camel-http >Reporter: Claus Ibsen >Priority: Minor > Fix For: 3.x > > > When mapping response http headers, then there is a filter strategy with 47 > known keys to skip. This is inefficient to loop the same 47 keys every time > and match against lower casing incoming http keys. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-16212) Build time route definition introspection API
[ https://issues.apache.org/jira/browse/CAMEL-16212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-16212: Component/s: camel-core > Build time route definition introspection API > - > > Key: CAMEL-16212 > URL: https://issues.apache.org/jira/browse/CAMEL-16212 > Project: Camel > Issue Type: New Feature > Components: camel-core >Reporter: Peter Palaga >Priority: Major > Fix For: 4.0 > > > We currently (mis)use the fact that current model classes have JAXB > annotations to discover CSimple expressions in Camel Quarkus - see > https://github.com/apache/camel-quarkus/blob/master/extensions/csimple/deployment/src/main/java/org/apache/camel/quarkus/component/csimple/deployment/CSimpleProcessor.java#L337-L347 > [~davsclaus] mentioned recently that he would like to remove JAXB from Camel > Core. It would be nice if Camel provided an API for route introspection at > build time before JAXB is removed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-16212) Build time route definition introspection API
[ https://issues.apache.org/jira/browse/CAMEL-16212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-16212: Fix Version/s: 4.0 (was: 3.x) > Build time route definition introspection API > - > > Key: CAMEL-16212 > URL: https://issues.apache.org/jira/browse/CAMEL-16212 > Project: Camel > Issue Type: New Feature >Reporter: Peter Palaga >Priority: Major > Fix For: 4.0 > > > We currently (mis)use the fact that current model classes have JAXB > annotations to discover CSimple expressions in Camel Quarkus - see > https://github.com/apache/camel-quarkus/blob/master/extensions/csimple/deployment/src/main/java/org/apache/camel/quarkus/component/csimple/deployment/CSimpleProcessor.java#L337-L347 > [~davsclaus] mentioned recently that he would like to remove JAXB from Camel > Core. It would be nice if Camel provided an API for route introspection at > build time before JAXB is removed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-16188) camel-kudu - Use test containers for testing
[ https://issues.apache.org/jira/browse/CAMEL-16188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-16188: Priority: Minor (was: Major) > camel-kudu - Use test containers for testing > > > Key: CAMEL-16188 > URL: https://issues.apache.org/jira/browse/CAMEL-16188 > Project: Camel > Issue Type: Test > Components: camel-kudu >Reporter: Claus Ibsen >Priority: Minor > Fix For: 3.x > > > We use a binary download for testing > https://kudu.apache.org/docs/developing.html#_using_the_kudu_binary_test_jar > Instead we should use test containers. then it can run as linux and always > work. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-16191) Camel-nitrite: enhance component to work with non-default serializer
[ https://issues.apache.org/jira/browse/CAMEL-16191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17599650#comment-17599650 ] Claus Ibsen commented on CAMEL-16191: - Jiri any update on this or we can abandon this > Camel-nitrite: enhance component to work with non-default serializer > > > Key: CAMEL-16191 > URL: https://issues.apache.org/jira/browse/CAMEL-16191 > Project: Camel > Issue Type: Improvement >Affects Versions: 3.8.0 >Reporter: Jiri Ondrusek >Assignee: Jiri Ondrusek >Priority: Minor > > It is possible to use nitrite with for example jackson serializerinstead of > default java serialization. (See > [https://github.com/nitrite/nitrite-java/blob/master/nitrite/src/main/java/org/dizitart/no2/mapper/JacksonMapper.java] > and > [https://github.com/nitrite/nitrite-java/issues/17#issuecomment-310963459]) > > It would be nice to enhance configuration of camel-nitrite to use different > serializer. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-16191) Camel-nitrite: enhance component to work with non-default serializer
[ https://issues.apache.org/jira/browse/CAMEL-16191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-16191: Priority: Minor (was: Major) > Camel-nitrite: enhance component to work with non-default serializer > > > Key: CAMEL-16191 > URL: https://issues.apache.org/jira/browse/CAMEL-16191 > Project: Camel > Issue Type: Improvement >Affects Versions: 3.8.0 >Reporter: Jiri Ondrusek >Assignee: Jiri Ondrusek >Priority: Minor > > It is possible to use nitrite with for example jackson serializerinstead of > default java serialization. (See > [https://github.com/nitrite/nitrite-java/blob/master/nitrite/src/main/java/org/dizitart/no2/mapper/JacksonMapper.java] > and > [https://github.com/nitrite/nitrite-java/issues/17#issuecomment-310963459]) > > It would be nice to enhance configuration of camel-nitrite to use different > serializer. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-16148) Provide m2e integration for camel-api-component-maven-plugin
[ https://issues.apache.org/jira/browse/CAMEL-16148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-16148. - Resolution: Won't Fix > Provide m2e integration for camel-api-component-maven-plugin > > > Key: CAMEL-16148 > URL: https://issues.apache.org/jira/browse/CAMEL-16148 > Project: Camel > Issue Type: New Feature > Components: tooling >Affects Versions: 3.7.1 >Reporter: Aurélien Pupier >Priority: Minor > > it would avoid errors when creating a new API component in an Eclipse desktop > workspace -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-16149) Provide m2e integration for camel-component-maven-plugin
[ https://issues.apache.org/jira/browse/CAMEL-16149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-16149. - Resolution: Won't Fix > Provide m2e integration for camel-component-maven-plugin > > > Key: CAMEL-16149 > URL: https://issues.apache.org/jira/browse/CAMEL-16149 > Project: Camel > Issue Type: New Feature > Components: tooling >Affects Versions: 3.7.1 >Reporter: Aurélien Pupier >Priority: Minor > > it woudl avoid errors in workspace when creating a component in an Eclipse > desktop workspace -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (CAMEL-16144) Create a camel-xchange-stream component
[ https://issues.apache.org/jira/browse/CAMEL-16144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen reassigned CAMEL-16144: --- Assignee: (was: James Netherton) > Create a camel-xchange-stream component > --- > > Key: CAMEL-16144 > URL: https://issues.apache.org/jira/browse/CAMEL-16144 > Project: Camel > Issue Type: New Feature >Reporter: Andrea Cosentino >Priority: Major > Fix For: 3.x > > > for the moment we are using the binance stuff from xchange. They are > providing also a stream-binance artifacts for streaming information. > > We could start with binance and maybe explore other API -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-16140) camel-core - Add option to eagerly build routes during build phase
[ https://issues.apache.org/jira/browse/CAMEL-16140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-16140. - Resolution: Won't Fix > camel-core - Add option to eagerly build routes during build phase > -- > > Key: CAMEL-16140 > URL: https://issues.apache.org/jira/browse/CAMEL-16140 > Project: Camel > Issue Type: Improvement > Components: camel-core >Reporter: Claus Ibsen >Priority: Major > Fix For: 3.x > > > We should look at moving more to build phase, so we can get ready for build > time optimization of routes as well. > Currently routes is setup at init phase, but we can start with adding an > option the end user can turn on to do this at build time. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-16143) Add druid component
[ https://issues.apache.org/jira/browse/CAMEL-16143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-16143. - Resolution: Abandoned > Add druid component > --- > > Key: CAMEL-16143 > URL: https://issues.apache.org/jira/browse/CAMEL-16143 > Project: Camel > Issue Type: New Feature > Components: camel-druid >Reporter: Jean-Baptiste Onofré >Assignee: Jean-Baptiste Onofré >Priority: Major > > The idea is to be able to interact with Druid broker to execute SQL query. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-16144) Create a camel-xchange-stream component
[ https://issues.apache.org/jira/browse/CAMEL-16144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-16144: Priority: Minor (was: Major) > Create a camel-xchange-stream component > --- > > Key: CAMEL-16144 > URL: https://issues.apache.org/jira/browse/CAMEL-16144 > Project: Camel > Issue Type: New Feature >Reporter: Andrea Cosentino >Priority: Minor > Fix For: 3.x > > > for the moment we are using the binance stuff from xchange. They are > providing also a stream-binance artifacts for streaming information. > > We could start with binance and maybe explore other API -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-16133) camel-thrift - Is TMultiplexProtocol not supported
[ https://issues.apache.org/jira/browse/CAMEL-16133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-16133: Priority: Major (was: Minor) > camel-thrift - Is TMultiplexProtocol not supported > -- > > Key: CAMEL-16133 > URL: https://issues.apache.org/jira/browse/CAMEL-16133 > Project: Camel > Issue Type: Improvement >Affects Versions: 3.7.0 >Reporter: fly >Priority: Major > Fix For: 3.x > > > How can I use TMultiplexProtocol in camel-thrift component? It doesn't seem > to support it -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-16133) camel-thrift - Is TMultiplexProtocol not supported
[ https://issues.apache.org/jira/browse/CAMEL-16133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-16133: Priority: Minor (was: Major) > camel-thrift - Is TMultiplexProtocol not supported > -- > > Key: CAMEL-16133 > URL: https://issues.apache.org/jira/browse/CAMEL-16133 > Project: Camel > Issue Type: Improvement >Affects Versions: 3.7.0 >Reporter: fly >Priority: Minor > Fix For: 3.x > > > How can I use TMultiplexProtocol in camel-thrift component? It doesn't seem > to support it -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-16121) camel-graphql - Optimize to prepare query / client on doInit
[ https://issues.apache.org/jira/browse/CAMEL-16121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-16121. - Resolution: Abandoned > camel-graphql - Optimize to prepare query / client on doInit > > > Key: CAMEL-16121 > URL: https://issues.apache.org/jira/browse/CAMEL-16121 > Project: Camel > Issue Type: Improvement > Components: camel-graphql >Reporter: Claus Ibsen >Priority: Minor > Fix For: 3.x > > > It uses a lazy in the getter. But we should initialize it in the doInit. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-16113) camel-core - Move more from init to build phase
[ https://issues.apache.org/jira/browse/CAMEL-16113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-16113: Fix Version/s: 4.0 (was: 3.x) > camel-core - Move more from init to build phase > --- > > Key: CAMEL-16113 > URL: https://issues.apache.org/jira/browse/CAMEL-16113 > Project: Camel > Issue Type: Improvement > Components: camel-core >Reporter: Claus Ibsen >Priority: Major > Fix For: 4.0 > > > We should look at moving more from init to build phase where its applicable. > This helps optimize core to startup faster and also for aot compilation with > graalvm or others where things can be done at build time. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-16100) camel-core - Normalizing endpoints (remove the double slash rule)
[ https://issues.apache.org/jira/browse/CAMEL-16100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-16100: Fix Version/s: 4.0 (was: 3.x) > camel-core - Normalizing endpoints (remove the double slash rule) > - > > Key: CAMEL-16100 > URL: https://issues.apache.org/jira/browse/CAMEL-16100 > Project: Camel > Issue Type: Improvement > Components: camel-core >Reporter: Claus Ibsen >Priority: Major > Fix For: 4.0 > > > endpoint such as > seda:foo > become seda://foo when normalized as it aided to match up similar endpoints, > such as http:apache.org vs http://apache.org, and file:foo vs file://foo > however the double slash is a bit annoying and today with some better > algorithm we can likely remove this rule, and make endpoint as-is. > And have better logic to match that http:apache.org and http://apache.org > would be the same etc. > However its rooted for soo long, so lets keep this in the backlog for v4 or > some day in v3 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-16097) camel-csimple - Runtime compile via Java JShell
[ https://issues.apache.org/jira/browse/CAMEL-16097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-16097. - Resolution: Won't Fix > camel-csimple - Runtime compile via Java JShell > --- > > Key: CAMEL-16097 > URL: https://issues.apache.org/jira/browse/CAMEL-16097 > Project: Camel > Issue Type: Improvement > Components: camel-core >Reporter: Claus Ibsen >Priority: Major > Fix For: 3.x > > > I wonder if we can use Java JShell as its intended for dynamic compile. > camel-k is adding support for jshell. > So when we go to Java 11 as minimum we can look into this. Or its a > requirement for camel-csimple-jshell etc. > Created a ticket to not forget about this -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-16044) camel-mutiny - Add integration to smallreye mutiny
[ https://issues.apache.org/jira/browse/CAMEL-16044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-16044. - Resolution: Duplicate > camel-mutiny - Add integration to smallreye mutiny > -- > > Key: CAMEL-16044 > URL: https://issues.apache.org/jira/browse/CAMEL-16044 > Project: Camel > Issue Type: Improvement >Reporter: Claus Ibsen >Priority: Major > Fix For: 3.x > > > https://github.com/smallrye/smallrye-mutiny > https://smallrye.io/smallrye-mutiny/ -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-16039) Reinstate Batch JMS Processing
[ https://issues.apache.org/jira/browse/CAMEL-16039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-16039: Fix Version/s: Future (was: 3.x) > Reinstate Batch JMS Processing > -- > > Key: CAMEL-16039 > URL: https://issues.apache.org/jira/browse/CAMEL-16039 > Project: Camel > Issue Type: New Feature > Components: camel-sjms >Affects Versions: 3.8.0 >Reporter: Brad Harvey >Priority: Major > Fix For: Future > > > Please provide a means of receiving multiple JMS messages as a batch in a > single transaction. > Our use case is to exchange JMS messages in order, quickly, with at least > once delivery guarantee, but over a link with 10 to 15 ms latency. > Processing multiple JMS messages in a single transaction is the way to meet > this requirement as it greatly reduces the chatter over the wire: > * For sending, we use the normal JMS component with a loop (using ) > inside the transaction. > * For receiving (in 3.4.5) we use sjms-batch with an aggregation strategy. > Example > ** from > sjms-batch:myqueue?aggregationStrategy=#groupedBodyAggregationStrategy=300=true=5000 > The sjms-batch component was removed as part of the overhaul of sjms, but > there appears to be no alternative to the functionality it provided. > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-16046) camel-ahc-ws client serving as both a producer and consumer
[
https://issues.apache.org/jira/browse/CAMEL-16046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-16046.
-
Resolution: Won't Fix
> camel-ahc-ws client serving as both a producer and consumer
> ---
>
> Key: CAMEL-16046
> URL: https://issues.apache.org/jira/browse/CAMEL-16046
> Project: Camel
> Issue Type: New Feature
> Components: camel-vertx-websocket
>Affects Versions: 2.23.4
> Environment: N/A
>Reporter: Josh West
>Priority: Major
> Fix For: 3.x
>
>
> While subscribing to a websocket using camel-ahc-ws the connection and
> session is sometimes bidirectional. A session may be initiated to subscribe
> to specific data points by sending a message over the same session as the
> producer (incoming) exchange.
>
> from("ahc-wss://ws-feed.example.com").routeId("incoming")
> .log("received message: ${body}");
>
>
> from("timer:wssfeedInitaitor?delay=10=1").routeId("feed-initiator")
> .setBody().constant(WSS_SUBSCRIBE)
> .to("ahc-wss://ws-feed.example.com")
> .log("received message on initiator: ${body}");
>
> The current behavior is that the "incoming" route connects but doesn't
> receive any data.
> The "feed-initiator" router successfully sends the subscribe message to the
> remote endpoint and starts receiving data. The websocket data received is
> only showing up in WsListener DEBUG logging messages "[cHttpClient-3-1]
> o.a.camel.component.ahc.ws.WsEndpoint : Received message --> ..." without the
> data on the exchange. The logging is coming from the "feed-initator" route,
> which is not logging messages using the route given the initiator is in wrong
> mode.
>
> Is there a way to share the same session?
>
> Otherwise can the component be enhanced to serve as both a producer and
> consumer at the same time?
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CAMEL-16036) Refactor Google PubSub testing support
[ https://issues.apache.org/jira/browse/CAMEL-16036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-16036. - Resolution: Fixed > Refactor Google PubSub testing support > -- > > Key: CAMEL-16036 > URL: https://issues.apache.org/jira/browse/CAMEL-16036 > Project: Camel > Issue Type: Improvement > Components: camel-google-pubsub >Affects Versions: 3.7.0 >Reporter: Preben Asmussen >Priority: Minor > Fix For: 3.x > > > This PR introduced message ordering > [https://github.com/apache/camel/pull/4877] and is related to CAMEL-16022. > We should refactor the component to only have one endpoint, let the emulator > use this, and if possible isolate as much emulator requirements to the test > setup eg. credentials asf. > See pr for conversation. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-16026) camel-vertx-rabbitmq - RabbitMQ component based on vertx
[ https://issues.apache.org/jira/browse/CAMEL-16026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-16026. - Resolution: Won't Fix > camel-vertx-rabbitmq - RabbitMQ component based on vertx > > > Key: CAMEL-16026 > URL: https://issues.apache.org/jira/browse/CAMEL-16026 > Project: Camel > Issue Type: New Feature > Components: camel-rabbitmq >Reporter: Claus Ibsen >Priority: Major > Fix For: 3.x > > > The old camel-rabbitmq has become a bit too cruft. So there is a new > camel-spring-rabbitmq that uses the spring rabbitmq client. > There is also a vertx rabbitmq client in the works (its rather new) but it > would be good to haver a camel-vertx-rabbitmq component using it, as it would > then be reactive, light, and work well with quarkus. > Then we can deprecate the old camel-rabbitmq component -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-16024) [camel-mongodb] ChangeStreams Consumer cannot handle string based _id
[
https://issues.apache.org/jira/browse/CAMEL-16024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-16024.
-
Resolution: Later
No response from user
> [camel-mongodb] ChangeStreams Consumer cannot handle string based _id
> -
>
> Key: CAMEL-16024
> URL: https://issues.apache.org/jira/browse/CAMEL-16024
> Project: Camel
> Issue Type: Improvement
> Components: camel-mongodb
>Affects Versions: 3.7.0
>Reporter: Dario Nuevo
>Assignee: Ramu
>Priority: Major
> Fix For: 3.x
>
>
> We're having quite a basic use case: Our documents in MongoDB have string
> based IDs (field _id) - as opposed to having ObjectId() instances. It seems,
> the current release of camel-mongodb cannot handle that.
> Having defined a route based on ChangeStreams like that:
> {code}
> from("mongodb:mongoConnection?database=db=changeStreams=coll")
> .routeId("changestream")
>.process("changeStreamProcessor")
>.to("stream:out");
> {code}
> When an event arrives on an object with a string based _id; I get this
> Exception:
> {code}
> Exception in thread "Camel (camel-1) thread #1 - mongodb://mongoConnection"
> org.bson.BsonInvalidOperationException: Value expected to be of type
> OBJECT_ID is of unexpected type STRING
> at org.bson.BsonValue.throwIfInvalidType(BsonValue.java:419)
> at org.bson.BsonValue.asObjectId(BsonValue.java:150)
> at org.bson.BsonDocument.getObjectId(BsonDocument.java:271)
> at
> org.apache.camel.component.mongodb.MongoDbChangeStreamsThread.doRun(MongoDbChangeStreamsThread.java:75)
> at
> org.apache.camel.component.mongodb.MongoAbstractConsumerThread.run(MongoAbstractConsumerThread.java:68)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:830)
> {code}
> So we basically have a problem here:
> https://github.com/apache/camel/blob/camel-3.7.0/components/camel-mongodb/src/main/java/org/apache/camel/component/mongodb/MongoDbChangeStreamsThread.java#L75
> So now the fix would be easy - check the type with _instanceof ObjectId_ and
> act accordingly - and i could also contribute that - but I'm not clear if
> that can succeed.
> As I see it, the _id is later set on the header as MongoDbConstants.MONGO_ID
> - which then also would be a string. IMHO that's totally fine, everybody
> knows what type their _id's have.
> How to resolve this? IMHO it's quite a normal use case to have
> non-ObjectId-IDs.. ;-)
> Thanks for any input
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CAMEL-16006) Improve ProducerTemplate documentation and code examples using ProducerTemplate
[
https://issues.apache.org/jira/browse/CAMEL-16006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-16006.
-
Resolution: Won't Fix
> Improve ProducerTemplate documentation and code examples using
> ProducerTemplate
> ---
>
> Key: CAMEL-16006
> URL: https://issues.apache.org/jira/browse/CAMEL-16006
> Project: Camel
> Issue Type: Improvement
> Components: documentation
>Affects Versions: 3.7.0
>Reporter: Thomas Küstermann
>Priority: Minor
>
> I'm currently reading about error handling in Camel, specifically [Using a
> Processor as a failure
> handler|https://camel.apache.org/manual/latest/exception-clause.html#ExceptionClause-UsingaProcessorasaFailureHandler].
> The code example lists
> {code:java|title=Code Example}
> // send it to our mock endpoint
> exchange.getContext().createProducerTemplate().send("mock:myerror", exchange);
> {code}
> According to the Javadoc of {{createProducerTemplate()}} and
> {{ProducerTemplate}} this is problematic:
> * {{stop()}} must be called when the {{ProducerTemplate}} is not further
> needed
> * Recommended practice is to use just one {{ProducerTemplate}} in the
> application
> * [Why does Camel use too many threads with
> ProducerTemplate?|https://camel.apache.org/manual/latest/faq/why-does-camel-use-too-many-threads-with-producertemplate.html]
> Since we're all lazy devs, we tend to copy paste code listings and think
> we're done.
> I suggest the following:
> * Add a section _Recommended Practice_ to [user manual
> ProducerTemplate|https://camel.apache.org/manual/latest/producertemplate.html]
> which basically lists the important bits of FAQ article [Why does Camel use
> too many threads with
> ProducerTemplate?|https://camel.apache.org/manual/latest/faq/why-does-camel-use-too-many-threads-with-producertemplate.html]
> * Fix code example in [Using a Processor as a failure
> handler|https://camel.apache.org/manual/latest/exception-clause.html#ExceptionClause-UsingaProcessorasaFailureHandler].
> * Maybe scan through other code samples?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-15981) Consider aligning gson versions accross camel dependencies
[ https://issues.apache.org/jira/browse/CAMEL-15981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-15981: Issue Type: Dependency upgrade (was: New Feature) > Consider aligning gson versions accross camel dependencies > -- > > Key: CAMEL-15981 > URL: https://issues.apache.org/jira/browse/CAMEL-15981 > Project: Camel > Issue Type: Dependency upgrade >Reporter: Alex Dettinger >Priority: Minor > Fix For: 3.x > > > See discussion in context here: > [https://github.com/apache/camel-quarkus/pull/2088#discussion_r546605397]. > Keep in mind that 2.8.6 doesn't work in OSGi. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-15981) Consider aligning gson versions accross camel dependencies
[ https://issues.apache.org/jira/browse/CAMEL-15981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17599646#comment-17599646 ] Claus Ibsen commented on CAMEL-15981: - We are on java 11 now > Consider aligning gson versions accross camel dependencies > -- > > Key: CAMEL-15981 > URL: https://issues.apache.org/jira/browse/CAMEL-15981 > Project: Camel > Issue Type: New Feature >Reporter: Alex Dettinger >Priority: Minor > > See discussion in context here: > [https://github.com/apache/camel-quarkus/pull/2088#discussion_r546605397]. > Keep in mind that 2.8.6 doesn't work in OSGi. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-15981) Consider aligning gson versions accross camel dependencies
[ https://issues.apache.org/jira/browse/CAMEL-15981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-15981: Fix Version/s: 3.x > Consider aligning gson versions accross camel dependencies > -- > > Key: CAMEL-15981 > URL: https://issues.apache.org/jira/browse/CAMEL-15981 > Project: Camel > Issue Type: New Feature >Reporter: Alex Dettinger >Priority: Minor > Fix For: 3.x > > > See discussion in context here: > [https://github.com/apache/camel-quarkus/pull/2088#discussion_r546605397]. > Keep in mind that 2.8.6 doesn't work in OSGi. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-15968) Camel-Braintree: Add more Gateway classes
[ https://issues.apache.org/jira/browse/CAMEL-15968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-15968: Priority: Minor (was: Major) > Camel-Braintree: Add more Gateway classes > - > > Key: CAMEL-15968 > URL: https://issues.apache.org/jira/browse/CAMEL-15968 > Project: Camel > Issue Type: Improvement > Components: camel-braintree >Reporter: Andrea Cosentino >Assignee: Andrea Cosentino >Priority: Minor > Fix For: 3.x > > > There are more gateway classes available, we should support them. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-15975) Camel Headers: Harmonize the usage a bit and add annotations for catalog
[ https://issues.apache.org/jira/browse/CAMEL-15975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-15975. - Fix Version/s: 3.x Resolution: Fixed We have headers in constant classes and they are annotated and in the metadata json > Camel Headers: Harmonize the usage a bit and add annotations for catalog > > > Key: CAMEL-15975 > URL: https://issues.apache.org/jira/browse/CAMEL-15975 > Project: Camel > Issue Type: Task >Reporter: Andrea Cosentino >Priority: Major > Fix For: 3.x > > > Headers ideally should be placed in classes like the constants classes we > have around the components. We should try to place this class always in the > same package, so we could be able to list the headers automatically in the > catalog and document them, we could also add some annotations for this > purpose, like a little description or something. This could be handy for > documentation but also for re-using catalog in subprojects. > [~cib...@e-ma.net] [~lb] [~nferraro] this is just a placeholder for > discussion and maybe find a way. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-15956) camel-core - Minimal core without routes
[ https://issues.apache.org/jira/browse/CAMEL-15956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-15956. - Resolution: Won't Fix > camel-core - Minimal core without routes > > > Key: CAMEL-15956 > URL: https://issues.apache.org/jira/browse/CAMEL-15956 > Project: Camel > Issue Type: Improvement > Components: camel-core >Reporter: Claus Ibsen >Assignee: Claus Ibsen >Priority: Major > Fix For: 3.x > > > It would be good to continue modularization and as we have camel-base and > camel-base-engine where in engine should be the routing engine. Then we > should work to make a BaseCamelContext implementation that end users can use > that does not have routing included. > The idea is to offer this to 3rd party frameworks that need as-minimal Camel > as possible. For example funqy (https://quarkus.io/guides/funqy) or vertx > mutiny, and others. > So they can integrate with Camel components via the camel-api via Producer, > Consumer, Endpoint etc and dont need the entire routing engine. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-15918) /releases/ page incomplete for camel-k
[ https://issues.apache.org/jira/browse/CAMEL-15918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-15918. - Resolution: Won't Fix > /releases/ page incomplete for camel-k > -- > > Key: CAMEL-15918 > URL: https://issues.apache.org/jira/browse/CAMEL-15918 > Project: Camel > Issue Type: Task >Reporter: Sebb >Priority: Major > > The releases page is missing earlier releases for: > camel-k > camel-k runtime > Only a single release is currently listed for each, however there are many > more: > https://archive.apache.org/dist/camel/camel-k/ > https://archive.apache.org/dist/camel/camel-k-runtime/ -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-15943) Support "oneOf" requirements of attributes inside the Catalog
[ https://issues.apache.org/jira/browse/CAMEL-15943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-15943: Fix Version/s: Future > Support "oneOf" requirements of attributes inside the Catalog > - > > Key: CAMEL-15943 > URL: https://issues.apache.org/jira/browse/CAMEL-15943 > Project: Camel > Issue Type: Improvement > Components: camel-catalog >Affects Versions: 3.7.0 >Reporter: Aurélien Pupier >Priority: Minor > Fix For: Future > > > There are some components that allow to configure an option on either > component or endpoint that would be required. > For instance the "operation" parameter for aws2-iam -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-15922) camel-core - Compiled simple support nested functions
[
https://issues.apache.org/jira/browse/CAMEL-15922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-15922:
Priority: Minor (was: Major)
> camel-core - Compiled simple support nested functions
> -
>
> Key: CAMEL-15922
> URL: https://issues.apache.org/jira/browse/CAMEL-15922
> Project: Camel
> Issue Type: Improvement
> Components: camel-core
>Affects Versions: 3.7.0
>Reporter: Claus Ibsen
>Priority: Minor
> Fix For: Future
>
>
> The csimple language does not support the following feature in its first
> release
> - nested functions (${xxx} inside existing ${xxx} functions))
> - the null safe operator (?)
> We need a smarter source code generator for this to support this, that
> supports building up multiple statements and assign to local variables, and
> branches for the null safe operator, and also to understand types of method
> calls for nested functions so its of the same type from the java compiler
> point of view.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-15922) camel-core - Compiled simple support nested functions
[
https://issues.apache.org/jira/browse/CAMEL-15922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-15922:
Fix Version/s: Future
(was: 3.x)
> camel-core - Compiled simple support nested functions
> -
>
> Key: CAMEL-15922
> URL: https://issues.apache.org/jira/browse/CAMEL-15922
> Project: Camel
> Issue Type: Improvement
> Components: camel-core
>Affects Versions: 3.7.0
>Reporter: Claus Ibsen
>Priority: Major
> Fix For: Future
>
>
> The csimple language does not support the following feature in its first
> release
> - nested functions (${xxx} inside existing ${xxx} functions))
> - the null safe operator (?)
> We need a smarter source code generator for this to support this, that
> supports building up multiple statements and assign to local variables, and
> branches for the null safe operator, and also to understand types of method
> calls for nested functions so its of the same type from the java compiler
> point of view.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CAMEL-15916) Add link to the Spring Docs about mongodb client
[
https://issues.apache.org/jira/browse/CAMEL-15916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-15916.
-
Resolution: Not A Problem
camel mongodb does not use spring
> Add link to the Spring Docs about mongodb client
>
>
> Key: CAMEL-15916
> URL: https://issues.apache.org/jira/browse/CAMEL-15916
> Project: Camel
> Issue Type: Improvement
> Components: camel-mongodb
>Affects Versions: 3.6.0
> Environment: Ubuntu 20.04
>Reporter: Andrii Melashchenko
>Priority: Minor
>
> Docs [https://camel.apache.org/components/latest/mongodb-component.html] do
> not have step to add
> ```
> {color:#e8bf6a}
> {color}{color:#e8bf6a}
> {color}{color:#e8bf6a} {color}spring-milestone{color:#e8bf6a}
> {color}{color:#e8bf6a} {color}Spring Maven MILESTONE
> Repository{color:#e8bf6a}
> {color}{color:#e8bf6a}
> {color}https://repo.spring.io/libs-milestone{color:#e8bf6a}
> {color}{color:#e8bf6a}
> {color}{color:#e8bf6a}{color}
> ```
> to pm.file in order to create mongoDB client according to
> [https://docs.spring.io/spring-data/mongodb/docs/current/reference/html/#reference]
>
> It's better to add direct link to spring to avoid this issue.
> Stack-overflow issue
> [https://stackoverflow.com/questions/61313732/configuration-problem-unable-to-locate-spring-namespacehandler-for-xml-schema-n/65125398#65125398]
>
> Later I'll add pull request to docs
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CAMEL-15912) Able to load custom font from file in camel-pdf
[ https://issues.apache.org/jira/browse/CAMEL-15912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17599639#comment-17599639 ] Claus Ibsen commented on CAMEL-15912: - Anyone has such a need, then welcome to help > Able to load custom font from file in camel-pdf > --- > > Key: CAMEL-15912 > URL: https://issues.apache.org/jira/browse/CAMEL-15912 > Project: Camel > Issue Type: New Feature > Components: camel-pdf >Reporter: Dmitry Volodin >Priority: Minor > Fix For: Future > > > There are 14 standard fonts provided OOB and not able to load custom fonts > from file in camel-pdf component > [Custom fonts with Apache PDFBox > component|https://carbonrider.github.io/pdfbox_tutorial/pdf_embed_font.html] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-15910) Missing release artifacts for Karaf and Spring Boot
[ https://issues.apache.org/jira/browse/CAMEL-15910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-15910. - Resolution: Abandoned > Missing release artifacts for Karaf and Spring Boot > --- > > Key: CAMEL-15910 > URL: https://issues.apache.org/jira/browse/CAMEL-15910 > Project: Camel > Issue Type: Task > Components: distribution >Affects Versions: 3.4.4, 3.6.0 >Reporter: Zoran Regvart >Assignee: Gregor Zurowski >Priority: Major > > We [need > to|https://www.apache.org/legal/release-policy.html#what-must-every-release-contain] > include source packages for Camel Karaf and Camel Spring Boot as they are > released with Camel core release. Since we split out Camel Karaf and Camel > Spring Boot sources of those also need to be present with hashes and > signatures in ASF distribution. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-15909) Camel AWS-KINESIS: Add KMS support
[ https://issues.apache.org/jira/browse/CAMEL-15909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17599637#comment-17599637 ] Claus Ibsen commented on CAMEL-15909: - What is the status of this > Camel AWS-KINESIS: Add KMS support > --- > > Key: CAMEL-15909 > URL: https://issues.apache.org/jira/browse/CAMEL-15909 > Project: Camel > Issue Type: New Feature > Components: camel-aws, camel-aws2 >Reporter: smaser >Assignee: Andrea Cosentino >Priority: Major > Labels: AWS > > Like SQS, Kinesis also supports KMS. Would be great to add options > KmsMasterKeyId and KmsDataKeyReusePeriodSeconds support. > https://aws.amazon.com/blogs/big-data/encrypt-and-decrypt-amazon-kinesis-records-using-aws-kms/ -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-15897) camel-bean - Optimize bean parameter binding
[ https://issues.apache.org/jira/browse/CAMEL-15897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-15897: Priority: Minor (was: Major) > camel-bean - Optimize bean parameter binding > > > Key: CAMEL-15897 > URL: https://issues.apache.org/jira/browse/CAMEL-15897 > Project: Camel > Issue Type: Improvement > Components: camel-core >Reporter: Claus Ibsen >Priority: Minor > Fix For: Future > > > Lets see if we can optimize camel-bean and the bean parameter binding, and > method call resolution that happens at runtime. > There are situations where we have type information and can optimize for > that, and also maybe have a source code generated way for optimal performance > and overhead, something like we have with csimple language. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-15885) AWS KINESIS component not de-aggregating producer side aggregated msgs
[
https://issues.apache.org/jira/browse/CAMEL-15885?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-15885.
-
Resolution: Won't Fix
we use aws2 now
> AWS KINESIS component not de-aggregating producer side aggregated msgs
> --
>
> Key: CAMEL-15885
> URL: https://issues.apache.org/jira/browse/CAMEL-15885
> Project: Camel
> Issue Type: New Feature
> Components: camel-aws
>Reporter: m
>Priority: Minor
>
> {code:java}
> 1.8.1.Final
>
> org.apache.camel.quarkus
> camel-quarkus-aws-kinesis
> {code}
>
> Our producer sends zipped messages. When reading those about 1/4 of all msgs
> cannot be unzipped. When digging into the message blob it became clear that
> one message contains multiple data blobs. That's probably due to the producer
> side message aggregation (
> [https://docs.aws.amazon.com/streams/latest/dev/kinesis-kpl-consumer-deaggregation.html]).
>
> Instead of a single message the data from the Record entity contains
> obviously several merged data blobs that I'm unable to read (zip error when
> trying to decompress). I'd expect to receive several msgs in my processor
> instead of several msgs merged into one msg blob.
>
> {code:java}
> from("aws-kinesis://" lsc.getStreamName()
> "?amazonKinesisClient=client=true=500=true=0=TRACE=LATEST")
> .routeId("vssKinesisStream")
> .log("LSC message received.")
>
> .onException(java.util.zip.ZipException.class).process(exchange ->
> { metrics.countInvalidPerSec(); }
> )
> .stop()
> .end()
> .process(exchange ->
> { metrics.countReceivedPerSec();
> Record record = exchange.getIn().getBody(Record.class);
> String message = extractMessageFromRecord(record);
> exchange.getIn().setBody(message);
> metrics.countValidPerSec(); LOG.info("Extracted
> message: " + message); lastReadMsgAge =
> Duration.between(record.getApproximateArrivalTimestamp().toInstant(),
> Instant.now()); }
> {code}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-15897) camel-bean - Optimize bean parameter binding
[ https://issues.apache.org/jira/browse/CAMEL-15897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-15897: Fix Version/s: Future (was: 3.x) > camel-bean - Optimize bean parameter binding > > > Key: CAMEL-15897 > URL: https://issues.apache.org/jira/browse/CAMEL-15897 > Project: Camel > Issue Type: Improvement > Components: camel-core >Reporter: Claus Ibsen >Priority: Major > Fix For: Future > > > Lets see if we can optimize camel-bean and the bean parameter binding, and > method call resolution that happens at runtime. > There are situations where we have type information and can optimize for > that, and also maybe have a source code generated way for optimal performance > and overhead, something like we have with csimple language. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-15883) Able to run multiple gRPC services on single endpoint (host:port)
[ https://issues.apache.org/jira/browse/CAMEL-15883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-15883. - Resolution: Abandoned > Able to run multiple gRPC services on single endpoint (host:port) > - > > Key: CAMEL-15883 > URL: https://issues.apache.org/jira/browse/CAMEL-15883 > Project: Camel > Issue Type: Improvement > Components: camel-grpc >Reporter: Dmitry Volodin >Priority: Major > Fix For: Future > > > There was a question on SO about this function > https://stackoverflow.com/questions/64972954/using-apache-camel-for-routing-grpc-traffic-using-the-same-port-per-route#new-answer -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-15869) Pagination to JPA component
[ https://issues.apache.org/jira/browse/CAMEL-15869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-15869. - Resolution: Won't Fix > Pagination to JPA component > --- > > Key: CAMEL-15869 > URL: https://issues.apache.org/jira/browse/CAMEL-15869 > Project: Camel > Issue Type: New Feature > Components: camel-jpa >Affects Versions: 3.6.0 >Reporter: Nemanja Žunić >Priority: Minor > Labels: features > > I would like to do a select query with pagination using JPA component. > I don't see existing support for something like that while it's a common > feature of JPA lib. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-15857) Reading done files along with the data files
[ https://issues.apache.org/jira/browse/CAMEL-15857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-15857. - Resolution: Won't Fix > Reading done files along with the data files > > > Key: CAMEL-15857 > URL: https://issues.apache.org/jira/browse/CAMEL-15857 > Project: Camel > Issue Type: New Feature > Components: camel-core >Reporter: Raju Parashar >Priority: Minor > > Currently, there is no out of the box support for reading done files while > consuming data files. > Often done files contain record count or other valuable information, which > are good candidates for validation. > So, there should be support for reading done files and populate exchange > headers -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-15838) Support microprofile openapi
[ https://issues.apache.org/jira/browse/CAMEL-15838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-15838. - Resolution: Abandoned > Support microprofile openapi > > > Key: CAMEL-15838 > URL: https://issues.apache.org/jira/browse/CAMEL-15838 > Project: Camel > Issue Type: New Feature >Reporter: Romain Manni-Bucau >Priority: Major > > Goal is to use microprofile openapi (therefore + jsonb) instead of > io.apicurio.datamodels and jackson. This enables MP applications using camel > to not rely on undesired 3rd party libraries. > MP OpenAPI provides a factory for its component (model) so this can be > portable. > Code is likely more or less the same than the existing one but with a fully > different stack. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-15853) camel-elasticsearch - Support SearchTemplateRequest
[ https://issues.apache.org/jira/browse/CAMEL-15853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17599633#comment-17599633 ] Claus Ibsen commented on CAMEL-15853: - Community users is welcome to help wit h this > camel-elasticsearch - Support SearchTemplateRequest > --- > > Key: CAMEL-15853 > URL: https://issues.apache.org/jira/browse/CAMEL-15853 > Project: Camel > Issue Type: New Feature > Components: camel-elasticsearch-rest >Reporter: Oliver Wulff >Priority: Minor > > The ElasticsearchProducer doesn't support the SearchTemplateRequest of the > high level REST client. > [https://github.com/apache/camel/blob/master/components/camel-elasticsearch-rest/src/main/java/org/apache/camel/component/elasticsearch/ElasticsearchProducer.java] > > The SearchTemplateRequest allows to execute a search by using an > Elasticsearch Search Template as described here: > https://www.elastic.co/guide/en/elasticsearch/client/java-rest/master/java-rest-high-search-template.html -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-15820) Hazelcast : improve search or create HazelcastInstance
[ https://issues.apache.org/jira/browse/CAMEL-15820?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17599630#comment-17599630 ] Claus Ibsen commented on CAMEL-15820: - Is this needed anymore? > Hazelcast : improve search or create HazelcastInstance > -- > > Key: CAMEL-15820 > URL: https://issues.apache.org/jira/browse/CAMEL-15820 > Project: Camel > Issue Type: Improvement >Reporter: Zineb Bendhiba >Assignee: Zineb Bendhiba >Priority: Minor > > Improve some code in the component, to compile in native mode for > camel-quarkus. > * The 2 methods *getOrCreateHzInstance* and *getOrCreateHzClientInstance* in > the class *HazelcastDefaultComponent*. vs parameters within the Endpoint. > Main point : Use parameters instead of reflection -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-15787) Netty in client mode (with pool) recreate sockets every 5 minutes
[ https://issues.apache.org/jira/browse/CAMEL-15787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-15787. - Resolution: Won't Fix > Netty in client mode (with pool) recreate sockets every 5 minutes > - > > Key: CAMEL-15787 > URL: https://issues.apache.org/jira/browse/CAMEL-15787 > Project: Camel > Issue Type: Improvement > Components: camel-netty >Affects Versions: 3.4.4, 3.6.0 >Reporter: Vladimir >Priority: Minor > > When using netty in client mode (create pool of connections). And do not send > any requests, all sockets in pool recreate every 5 minutes. > It is strange private long producerPoolMinEvictableIdle = 5 * 60 * 1000L > config for apache common pool. Default value must be bigger and do not > recreate all sockets every 5 minutes -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-15755) Spring Boot tests broken when using TestInstance.Lifecycle.PER_CLASS
[
https://issues.apache.org/jira/browse/CAMEL-15755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-15755.
-
Resolution: Abandoned
> Spring Boot tests broken when using TestInstance.Lifecycle.PER_CLASS
>
>
> Key: CAMEL-15755
> URL: https://issues.apache.org/jira/browse/CAMEL-15755
> Project: Camel
> Issue Type: Improvement
> Components: camel-spring, camel-test
>Affects Versions: 3.6.0
>Reporter: Alex Arana
>Priority: Minor
> Fix For: 3.x
>
>
> After upgrading to {{3.6.0}} existing Spring Boot tests in my codebase
> started to fail. After some investigation I discovered that this is due to my
> unit tests having a single instance per class as configured using JUnit's
> {{@TestInstance(TestInstance.Lifecycle.PER_CLASS)}}
> Some changes were introduced in a recent commit that affected the existing
> behaviour in CamelSpringBootExecutionListener:
> [https://github.com/apache/camel/commit/efc34ab2b98f3697ebb482cf1645fda6f0794797]
> I have remediated my tests by running the following code in a JUnit
> BeforeEach method within a base test class:
> {code:java}
> // Kotlin
> @BeforeEach
> fun init() {
> SpringCamelContext.setNoStart(false)
> camelContext.start()
> }
> {code}
> I am currently looking for a more permanent solution to this issue that
> properly supports single instance JUnit5 Test classes.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-15762) camel-core - Move constants on Exchange to its own class
[ https://issues.apache.org/jira/browse/CAMEL-15762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-15762: Fix Version/s: 4.0 (was: Future) > camel-core - Move constants on Exchange to its own class > > > Key: CAMEL-15762 > URL: https://issues.apache.org/jira/browse/CAMEL-15762 > Project: Camel > Issue Type: Improvement > Components: camel-core >Reporter: Claus Ibsen >Priority: Major > Fix For: 4.0 > > > We have many constants on the Exchange interface. But its discouraged to have > that on interfaces. > If we have a constant class instead to keep those on that would be better. > But the Exchange have had these for a long time, os its maybe a Camel 4 > change. > This also helps reduce the object size of Exchange instances in memory as > they dont have reference to those 100+ constants. Today they take up space, > and an empty exchange is around 1000-1500 bytes. Its actuall the class > instance that takes up extra memory. So not sure if the instances of > DefaultExchange will reduce memory, but constant fields on interface is > regarded as anti pattern by Java experts. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-15780) Make camel-openapi-java use Jsonb instead of Jackson
[ https://issues.apache.org/jira/browse/CAMEL-15780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-15780. - Resolution: Won't Fix > Make camel-openapi-java use Jsonb instead of Jackson > > > Key: CAMEL-15780 > URL: https://issues.apache.org/jira/browse/CAMEL-15780 > Project: Camel > Issue Type: Task > Components: rest >Affects Versions: 3.6.0 >Reporter: Romain Manni-Bucau >Priority: Major > > Goal are: > # Ensure user can rely on its JSON-Java mapper implementation > # Reduce the size of the dependency tree for that concern (openapi > generation) but still use camel integration with the rest DSL > If it helps we can extract the model from > [https://github.com/apache/geronimo-openapi/tree/master/geronimo-openapi-impl/src/main/java/org/apache/geronimo/microprofile/openapi/impl/model] > in its own jar -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-15744) camel-micrometer: add ability to get micrometer metrics from Kafka Client
[ https://issues.apache.org/jira/browse/CAMEL-15744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-15744: Fix Version/s: Future > camel-micrometer: add ability to get micrometer metrics from Kafka Client > - > > Key: CAMEL-15744 > URL: https://issues.apache.org/jira/browse/CAMEL-15744 > Project: Camel > Issue Type: Improvement > Components: camel-kafka, camel-micrometer >Reporter: Stefan Stus >Priority: Minor > Fix For: Future > > > > In Mirometer introduces an ability to get technical metrics from Kafka's > consumers and producers. > It seems to be production-ready since 1.5.4 based on our production > experience and available since 1.4.0. > See: [Micrometer > implementation|https://github.com/micrometer-metrics/micrometer/blob/master/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/kafka/KafkaClientMetrics.java] > > I tried to add a custom implementation to my project to extract those metrics > from Camel. I found out that I'm unable to do it for the Kafka Consumer since > the actual Kafka Consumer hides [deeply > inside|https://github.com/apache/camel/blob/master/components/camel-kafka/src/main/java/org/apache/camel/component/kafka/KafkaConsumer.java#L174-L176] > KafkaConsumer Camel class. > At the same time, I'm able to get KafkaProducer from Camel class [here. > |https://github.com/apache/camel/blob/master/components/camel-kafka/src/main/java/org/apache/camel/component/kafka/KafkaProducer.java#L83] > > *Desired Solution:* > Add additional CamelKafkaMicrometerRoutePolicy to extract Kafka technical > metrics. > Add the ability to inject CamelKafkaMicrometerRoutePolicy into Consumer and > Producer components. > > Will this feature be welcomed in Camel? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-15744) camel-micrometer: add ability to get micrometer metrics from Kafka Client
[ https://issues.apache.org/jira/browse/CAMEL-15744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17599628#comment-17599628 ] Claus Ibsen commented on CAMEL-15744: - does opentelemetry have something for kafka as this component is what we prioritize > camel-micrometer: add ability to get micrometer metrics from Kafka Client > - > > Key: CAMEL-15744 > URL: https://issues.apache.org/jira/browse/CAMEL-15744 > Project: Camel > Issue Type: Improvement > Components: camel-kafka, camel-micrometer >Reporter: Stefan Stus >Priority: Minor > > > In Mirometer introduces an ability to get technical metrics from Kafka's > consumers and producers. > It seems to be production-ready since 1.5.4 based on our production > experience and available since 1.4.0. > See: [Micrometer > implementation|https://github.com/micrometer-metrics/micrometer/blob/master/micrometer-core/src/main/java/io/micrometer/core/instrument/binder/kafka/KafkaClientMetrics.java] > > I tried to add a custom implementation to my project to extract those metrics > from Camel. I found out that I'm unable to do it for the Kafka Consumer since > the actual Kafka Consumer hides [deeply > inside|https://github.com/apache/camel/blob/master/components/camel-kafka/src/main/java/org/apache/camel/component/kafka/KafkaConsumer.java#L174-L176] > KafkaConsumer Camel class. > At the same time, I'm able to get KafkaProducer from Camel class [here. > |https://github.com/apache/camel/blob/master/components/camel-kafka/src/main/java/org/apache/camel/component/kafka/KafkaProducer.java#L83] > > *Desired Solution:* > Add additional CamelKafkaMicrometerRoutePolicy to extract Kafka technical > metrics. > Add the ability to inject CamelKafkaMicrometerRoutePolicy into Consumer and > Producer components. > > Will this feature be welcomed in Camel? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-15746) json-path - Add support for jsonsurfer for streaming splitting
[ https://issues.apache.org/jira/browse/CAMEL-15746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-15746. - Resolution: Won't Fix > json-path - Add support for jsonsurfer for streaming splitting > -- > > Key: CAMEL-15746 > URL: https://issues.apache.org/jira/browse/CAMEL-15746 > Project: Camel > Issue Type: Improvement > Components: camel-jsonpath >Reporter: Claus Ibsen >Assignee: Matej Melko >Priority: Major > Fix For: 3.x > > > It would be good to add support for > https://github.com/jsurfer/JsonSurfer > So we can plug that into camel-jsonpath (and others) and then you can use > that in streaming mode, such as splitting big json files (GB sizes). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-15729) Graphql integration does not allow for TLS using private CAs
[ https://issues.apache.org/jira/browse/CAMEL-15729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-15729: Fix Version/s: Future > Graphql integration does not allow for TLS using private CAs > > > Key: CAMEL-15729 > URL: https://issues.apache.org/jira/browse/CAMEL-15729 > Project: Camel > Issue Type: New Feature > Components: camel-graphql >Affects Versions: 3.6.0 > Environment: OCP 4.5 on X using Apache Camel Operator 1.2.0, but > other environments apply as well. >Reporter: Tim Kaczynski >Priority: Minor > Fix For: Future > > > This enhancement request was generated from a question on zulipchat: > [https://camel.zulipchat.com/#narrow/stream/257298-camel/topic/Adding.20a.20trustStore.20for.20graphql/near/213944005] > We are writing an integration that needs to produce messages to a graphql > server. The graphql server is using TLS and its certificate was generated by > an internal CA. There does not appear to be a way to provide a trust store > to the graphql producer, like there is for say the Kafka integrations. > Connections to graphql fail due to the inability to build a trusted > certificate chain. > Possible non-trivial solutions include assuming the graphql integration is > using the apache HTTP client, and setting up a new protocol that uses a > custom trust store. Also (using camel-k) using the JVM taint to alter the > JSSE configuration / java properties, adding a trust store containing the CA. > However both of these solutions require assumptions about the implementation > that may not always be true (and we have not tested them yet). Could also > use the HTTP[4] integration directly to talk to graphql but this requires > coding the REST request manually. > If there were a parameter on the graphql integration where we could input a > trust store, type, and password, that would be an ideal solution. Or perhaps > some other way of modifying the default trust store using camel-k (this would > benefit all integrations). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-15720) camel-core - Optimize calling bean with noarg method
[ https://issues.apache.org/jira/browse/CAMEL-15720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-15720. - Resolution: Abandoned > camel-core - Optimize calling bean with noarg method > > > Key: CAMEL-15720 > URL: https://issues.apache.org/jira/browse/CAMEL-15720 > Project: Camel > Issue Type: Improvement > Components: camel-core >Reporter: Claus Ibsen >Assignee: Claus Ibsen >Priority: Major > Fix For: 3.x > > > When using bean language, method call, ref etc and a method name is specified > and its a noarg method (or args is hardcoded) then we can optimize to do less > discovery on each invocation and reuse last discovery. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-15717) Skip archetype integration tests in deploy profile
[ https://issues.apache.org/jira/browse/CAMEL-15717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-15717. - Resolution: Abandoned > Skip archetype integration tests in deploy profile > -- > > Key: CAMEL-15717 > URL: https://issues.apache.org/jira/browse/CAMEL-15717 > Project: Camel > Issue Type: Task > Components: build system >Reporter: Jan Bednar >Assignee: Jan Bednar >Priority: Major > Fix For: 3.x > > > See problems during latest release > http://camel.465427.n5.nabble.com/Apache-Camel-3-6-this-October-tp5887752p5889984.html -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-15729) Graphql integration does not allow for TLS using private CAs
[ https://issues.apache.org/jira/browse/CAMEL-15729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-15729: Priority: Minor (was: Major) > Graphql integration does not allow for TLS using private CAs > > > Key: CAMEL-15729 > URL: https://issues.apache.org/jira/browse/CAMEL-15729 > Project: Camel > Issue Type: New Feature > Components: camel-graphql >Affects Versions: 3.6.0 > Environment: OCP 4.5 on X using Apache Camel Operator 1.2.0, but > other environments apply as well. >Reporter: Tim Kaczynski >Priority: Minor > > This enhancement request was generated from a question on zulipchat: > [https://camel.zulipchat.com/#narrow/stream/257298-camel/topic/Adding.20a.20trustStore.20for.20graphql/near/213944005] > We are writing an integration that needs to produce messages to a graphql > server. The graphql server is using TLS and its certificate was generated by > an internal CA. There does not appear to be a way to provide a trust store > to the graphql producer, like there is for say the Kafka integrations. > Connections to graphql fail due to the inability to build a trusted > certificate chain. > Possible non-trivial solutions include assuming the graphql integration is > using the apache HTTP client, and setting up a new protocol that uses a > custom trust store. Also (using camel-k) using the JVM taint to alter the > JSSE configuration / java properties, adding a trust store containing the CA. > However both of these solutions require assumptions about the implementation > that may not always be true (and we have not tested them yet). Could also > use the HTTP[4] integration directly to talk to graphql but this requires > coding the REST request manually. > If there were a parameter on the graphql integration where we could input a > trust store, type, and password, that would be an ideal solution. Or perhaps > some other way of modifying the default trust store using camel-k (this would > benefit all integrations). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-15709) Component for azure loganalytics similar to splunk
[ https://issues.apache.org/jira/browse/CAMEL-15709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-15709: Fix Version/s: Future (was: 3.x) > Component for azure loganalytics similar to splunk > -- > > Key: CAMEL-15709 > URL: https://issues.apache.org/jira/browse/CAMEL-15709 > Project: Camel > Issue Type: New Feature > Components: camel-azure >Reporter: Tibin Lukose >Priority: Major > Fix For: Future > > Original Estimate: 168h > Remaining Estimate: 168h > > A producer for azure log analytics for forwarding the logs, similar to what > we have for splunk HEC -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-15703) camel-core - Optional API on Exchange / Message
[ https://issues.apache.org/jira/browse/CAMEL-15703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-15703. - Resolution: Won't Fix > camel-core - Optional API on Exchange / Message > --- > > Key: CAMEL-15703 > URL: https://issues.apache.org/jira/browse/CAMEL-15703 > Project: Camel > Issue Type: New Feature > Components: camel-core >Reporter: Claus Ibsen >Priority: Major > Fix For: 3.x > > > I wonder if we should add methods to Exchange and Message that uses > java.util.Option as return value. > Optional getOptionalProperty(String name) > Optional getOptionalProperty(String name, Class type) > And ditto for Message with its header and body (although a null body is much > more rare) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-15412) camel-box - No way to set OutputStream option
[
https://issues.apache.org/jira/browse/CAMEL-15412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17599601#comment-17599601
]
Michael Genereux commented on CAMEL-15412:
--
[~davsclaus], is it not a bug because the workaround using a processor solves
it?
> camel-box - No way to set OutputStream option
> -
>
> Key: CAMEL-15412
> URL: https://issues.apache.org/jira/browse/CAMEL-15412
> Project: Camel
> Issue Type: Improvement
> Components: camel-box
>Affects Versions: 3.4.2
>Reporter: Michael Genereux
>Priority: Major
>
> I want to download a file from Box and the setHeader doesn't accept objects
> when setting the header. The required output parameter is a OutputStream.
> The integration tests use the component directly as opposed to the URLs or
> setHeader methods. I would have expected the outputstream payload to be in
> the Message coming out of the endpoint. The REST component documentation
> looks more like what I was expecting.
> My variation of the example from the docs that doesn't work:
> {code:java}
> from("timer:test?period=3600")
> .setHeader("CamelBox.fileId", constant("12345678")
> .setHeader("CamelBox.output", new ByteArrayOutputStream())
> .to("box://files/download")
> .to("file://out");
> {code}
> Using Camel thinking, I tried this code first but I understand if this
> component wants to be special with its headers and stuff.
> {code:java}
> from("timer:test?period=3600")
>.to("box://files/download?fileId=123456789")
>.to("file://out");
> {code}
> Again, please let me know what I can do to help.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CAMEL-15672) Camel-AWS2-Translate: Support batch translation job
[ https://issues.apache.org/jira/browse/CAMEL-15672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17599593#comment-17599593 ] Claus Ibsen commented on CAMEL-15672: - Is this any relevant? Is there a high demand for a lot of translation so you need to batch the jobs ? > Camel-AWS2-Translate: Support batch translation job > --- > > Key: CAMEL-15672 > URL: https://issues.apache.org/jira/browse/CAMEL-15672 > Project: Camel > Issue Type: Improvement > Components: camel-aws2 >Reporter: Andrea Cosentino >Assignee: Andrea Cosentino >Priority: Major > Fix For: 3.x > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-15683) camel-mm7 - Component for sending MMS cellular messages
[ https://issues.apache.org/jira/browse/CAMEL-15683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-15683. - Resolution: Abandoned > camel-mm7 - Component for sending MMS cellular messages > --- > > Key: CAMEL-15683 > URL: https://issues.apache.org/jira/browse/CAMEL-15683 > Project: Camel > Issue Type: New Feature >Reporter: Claus Ibsen >Priority: Major > Fix For: 3.x > > > It would be good to have a camel component for being able to send cellular > text messages (SMS and MMS) via the mm7 protocol. > This protocol is SOAP based (yeah old world) send to mm7 server via HTTP. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-15657) JDK biased locking to be removed in Java 17
[ https://issues.apache.org/jira/browse/CAMEL-15657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-15657. - Resolution: Not A Problem > JDK biased locking to be removed in Java 17 > --- > > Key: CAMEL-15657 > URL: https://issues.apache.org/jira/browse/CAMEL-15657 > Project: Camel > Issue Type: Task > Components: camel-core >Reporter: Claus Ibsen >Priority: Major > Fix For: 3.x > > > jdk15 initiated the process of removing *biased locking* from the JVM as > per JEP 374 (https://openjdk.java.net/jeps/374). That release switched > the default setting from enabled to disabled. The plan is to see if any > users squeal and, if not, proceed to remove it in jdk16 or jdk17. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-15640) Partition component/EIP
[
https://issues.apache.org/jira/browse/CAMEL-15640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-15640.
-
Resolution: Won't Fix
> Partition component/EIP
> ---
>
> Key: CAMEL-15640
> URL: https://issues.apache.org/jira/browse/CAMEL-15640
> Project: Camel
> Issue Type: New Feature
>Reporter: Jan Bednar
>Assignee: Jan Bednar
>Priority: Minor
>
> Sometimes you need to process messages in parallel and also ensure order of
> messages per key. Kafka is great for this with its partitioning and ActiveMQ
> with message groups, but in small single instance project may be broker
> overkill.
> I needed that feature in one project and solved it with something what doesnt
> look nice, similar to this pseudo code:
> {code:java}
> final int consumers = 10;
> from("direct:source")
> .process(exchange ->
> exchange.getMessage().setHeader("partition",
> exchange.getMessage().getHeader("partition_key")
> .hashCode() % consumers)
> )
> .toD("seda:partition_${header.partition}");
> for (int i = 0; i < consumers; i++) {
> from("seda:partition_" + i)
> .to("direct:target");
> }
> {code}
> It would be great to have something like Partition component (*or maybe
> better Partition EIP?*)
> It can be similar to seda, but with following features.
> * Pluggable PartitionStrategy with pluggable Expression for partition key.
> Default can be HashPartitionStrategy.
> * Message will be assigned to Thread based on following algorithm:
> _target_thread_id = hash % concurrentConsumers_
>
>
> *Community feedback/discussion about this feature welcomed.*
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
