[jira] [Updated] (CAMEL-19684) tests: cleanup flaky tests
[ https://issues.apache.org/jira/browse/CAMEL-19684?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Otavio Rodolfo Piske updated CAMEL-19684: - Description: We had a green build on 1054. Now we need to continue squashing the flaky tests. The current list of flakies: * org.apache.camel.component.aws2.sqs.SqsBatchConsumerConcurrentConsumersIT.receiveBatch * -org.apache.camel.component.file.watch.FileWatchComponentTest.testAntMatcher- * org.apache.camel.component.file.FileRecursiveNoopTest.testRecursiveNoop * org.apache.camel.component.undertow.DefaultUndertowHttpBindingTest.readEntireDelayedPayload * org.apache.camel.component.flatpack.FixedLengthAllowShortTest.testFlatpackDataFormatXML * org.apache.camel.component.rocketmq.RocketMQRequestReplyRouteTest.testRouteMessageInRequestReplyMode * -org.apache.camel.component.stomp.StompConsumerHeaderFilterStrategyTest.testConsume- * org.apache.camel.component.jetty.JettySuspendWhileInProgressTest.testJettySuspendWhileInProgress * org.apache.camel.routepolicy.quartz.CronScheduledRoutePolicyTest$CronTest1.testScheduledStartRoutePolicyWithTwoRoutes * org.apache.camel.component.quartz.QuartzAddRoutesAfterCamelContextStartedTest.testAddRoutes * -org.apache.camel.component.zookeepermaster.MasterEndpointIT.testEndpoint- * org.apache.camel.component.zookeepermaster.group.GroupIT.testRejoinAfterDisconnect * org.apache.camel.component.jms.JmsFormatDateHeadersToIso8601Test.testBindingFormatDateHeaderToIso8601 * org.apache.camel.component.rocketmq.RocketMQRouteTest.testSimpleRoute * org.apache.camel.component.rocketmq.RocketMQRequestReplyRouteTest.testRouteMessageInRequestReplyMode * org.apache.camel.processor.RecipientListWithSimpleExpressionTest.testRecipientList * org.apache.camel.component.kafka.integration.KafkaConsumerAutoInstResumeRouteStrategyIT.testOffsetIsBeingChecked * org.apache.camel.management.ManagedPooledExchangeTest.testSameExchange (new in build 1069) was: We had a green build on 1054. Now we need to continue squashing the flaky tests. The current list of flakies: * org.apache.camel.component.aws2.sqs.SqsBatchConsumerConcurrentConsumersIT.receiveBatch * org.apache.camel.component.file.watch.FileWatchComponentTest.testAntMatcher * org.apache.camel.component.file.FileRecursiveNoopTest.testRecursiveNoop * org.apache.camel.component.undertow.DefaultUndertowHttpBindingTest.readEntireDelayedPayload * org.apache.camel.component.flatpack.FixedLengthAllowShortTest.testFlatpackDataFormatXML * org.apache.camel.component.rocketmq.RocketMQRequestReplyRouteTest.testRouteMessageInRequestReplyMode * -org.apache.camel.component.stomp.StompConsumerHeaderFilterStrategyTest.testConsume- * org.apache.camel.component.jetty.JettySuspendWhileInProgressTest.testJettySuspendWhileInProgress * org.apache.camel.routepolicy.quartz.CronScheduledRoutePolicyTest$CronTest1.testScheduledStartRoutePolicyWithTwoRoutes * org.apache.camel.component.quartz.QuartzAddRoutesAfterCamelContextStartedTest.testAddRoutes * -org.apache.camel.component.zookeepermaster.MasterEndpointIT.testEndpoint- * org.apache.camel.component.zookeepermaster.group.GroupIT.testRejoinAfterDisconnect * org.apache.camel.component.jms.JmsFormatDateHeadersToIso8601Test.testBindingFormatDateHeaderToIso8601 * org.apache.camel.component.rocketmq.RocketMQRouteTest.testSimpleRoute * org.apache.camel.component.rocketmq.RocketMQRequestReplyRouteTest.testRouteMessageInRequestReplyMode * org.apache.camel.processor.RecipientListWithSimpleExpressionTest.testRecipientList * org.apache.camel.component.kafka.integration.KafkaConsumerAutoInstResumeRouteStrategyIT.testOffsetIsBeingChecked * org.apache.camel.management.ManagedPooledExchangeTest.testSameExchange (new in build 1069) > tests: cleanup flaky tests > -- > > Key: CAMEL-19684 > URL: https://issues.apache.org/jira/browse/CAMEL-19684 > Project: Camel > Issue Type: Task > Components: camel-aws2, camel-file-watch, camel-quartz, > camel-undertow, camel-zookeeper-master >Reporter: Otavio Rodolfo Piske >Priority: Major > Labels: easy, help-wanted > > We had a green build on 1054. Now we need to continue squashing the flaky > tests. > The current list of flakies: > * > org.apache.camel.component.aws2.sqs.SqsBatchConsumerConcurrentConsumersIT.receiveBatch > * > -org.apache.camel.component.file.watch.FileWatchComponentTest.testAntMatcher- > * org.apache.camel.component.file.FileRecursiveNoopTest.testRecursiveNoop > * > org.apache.camel.component.undertow.DefaultUndertowHttpBindingTest.readEntireDelayedPayload > * > org.apache.camel.component.flatpack.FixedLengthAllowShortTest.testFlatpackDataFormatXML > * > org.apache.camel.component.rocketmq.RocketMQRequestReplyRouteTest.testRouteMessageInRequestReplyMode > * > -org.apache.camel.component.stomp.StompConsumerHea
[jira] [Assigned] (CAMEL-19516) camel-consul: replace Thread.sleep in tests
[ https://issues.apache.org/jira/browse/CAMEL-19516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Otavio Rodolfo Piske reassigned CAMEL-19516: Assignee: Nikita Konovalov > camel-consul: replace Thread.sleep in tests > --- > > Key: CAMEL-19516 > URL: https://issues.apache.org/jira/browse/CAMEL-19516 > Project: Camel > Issue Type: Task > Components: camel-consul, tests >Affects Versions: 4.0.0 >Reporter: Otavio Rodolfo Piske >Assignee: Nikita Konovalov >Priority: Minor > Labels: easy, help-wanted > > We have many tests which use Thread.sleep for synchronization. This is bug > prone and can introduce flakiness when running on environments with different > capacities. > Ideally we should replace these with: > * [Awaitility|http://www.awaitility.org/] > * Java's native syncronization mechanism (Latches, Phasers, Locks, etc) > * Nothing (i.e.; in some cases the sleep can simply be removed) > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (CAMEL-19518) camel-disruptor: replace Thread.sleep in tests
[ https://issues.apache.org/jira/browse/CAMEL-19518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Otavio Rodolfo Piske reassigned CAMEL-19518: Assignee: Nikita Konovalov > camel-disruptor: replace Thread.sleep in tests > -- > > Key: CAMEL-19518 > URL: https://issues.apache.org/jira/browse/CAMEL-19518 > Project: Camel > Issue Type: Task > Components: camel-disruptor, tests >Affects Versions: 4.0.0 >Reporter: Otavio Rodolfo Piske >Assignee: Nikita Konovalov >Priority: Minor > Labels: easy, help-wanted > > We have many tests which use Thread.sleep for synchronization. This is bug > prone and can introduce flakiness when running on environments with different > capacities. > Ideally we should replace these with: > * [Awaitility|http://www.awaitility.org/] > * Java's native syncronization mechanism (Latches, Phasers, Locks, etc) > * Nothing (i.e.; in some cases the sleep can simply be removed) > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-19650) Camel Kafka doesn't honor 'workerPool' configuration
[
https://issues.apache.org/jira/browse/CAMEL-19650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17752641#comment-17752641
]
Claus Ibsen commented on CAMEL-19650:
-
https://issues.apache.org/jira/projects/CAMEL?selectedItem=com.atlassian.jira.jira-projects-plugin%3Arelease-page&status=released-unreleased
> Camel Kafka doesn't honor 'workerPool' configuration
>
>
> Key: CAMEL-19650
> URL: https://issues.apache.org/jira/browse/CAMEL-19650
> Project: Camel
> Issue Type: Bug
> Components: camel-kafka
>Affects Versions: 3.14.9
> Environment: Java - 8
> Camel 3.14.9
> Kafka 3.x broker
>Reporter: Kartik
>Priority: Minor
> Labels: camel-component
> Fix For: 3.14.10, 3.20.7, 3.21.1, 3.22.0, 4.0.0
>
>
> When we set the "{*}workerPool"{*} property in the Kafka configuration it's
> not honored and "KafkaProducer" falls back to creating a new thread pool with
> the default 10 threads.
>
> As mentioned in
> [https://camel.apache.org/components/3.14.x/kafka-component.html#_component_options]
> There is a component option to provide custom thread pool "{*}workerPool
> (producer){*}"
>
> So in KafkaProducer.java
>
> {code:java}
> // code placeholder
> @Override
> @SuppressWarnings("rawtypes")
> protected void doStart() throws Exception {
> Properties props = getProps();
> if (kafkaProducer == null) {
> createProducer(props);
> }
> // if we are in asynchronous mode we need a worker pool
> if (!configuration.isSynchronous() && workerPool == null) {
> workerPool = endpoint.createProducerExecutor();
> // we create a thread pool so we should also shut it down
> shutdownWorkerPool = true;
> }
> }
> {code}
> " _*if (!configuration.isSynchronous() && workerPool == null) {*_ "
> we only check for synchronization, since the worker pool is "null" when
> created, it goes ahead and creates a new pool with default threads by calling
> "createProducerExecutor()"
>
> Ideally, we should check if "configuration.getWorkerPool()" and if it's not
> null, we should assign this to the worker pool instead of creating the new
> one.
>
> Fix.
>
> {code:java}
> // code placeholder
> protected void doStart() throws Exception {
> Properties props = this.getProps();
> if (this.kafkaProducer == null) {
> this.createProducer(props);
> }
> if (!this.configuration.isSynchronous() && this.workerPool == null) {
> if (this.configuration.getWorkerPool() != null) {
> this.workerPool = this.configuration.getWorkerPool();
> this.shutdownWorkerPool = false;
> } else {
> this.workerPool = this.endpoint.createProducerExecutor();
> this.shutdownWorkerPool = true;
> }
> }
> } {code}
>
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CAMEL-19650) Camel Kafka doesn't honor 'workerPool' configuration
[
https://issues.apache.org/jira/browse/CAMEL-19650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17752623#comment-17752623
]
Kartik commented on CAMEL-19650:
[~davsclaus] [~nfilotto] When 3.14.10 is getting released, we need to consume
this fix as we have 1000+ routes running.
> Camel Kafka doesn't honor 'workerPool' configuration
>
>
> Key: CAMEL-19650
> URL: https://issues.apache.org/jira/browse/CAMEL-19650
> Project: Camel
> Issue Type: Bug
> Components: camel-kafka
>Affects Versions: 3.14.9
> Environment: Java - 8
> Camel 3.14.9
> Kafka 3.x broker
>Reporter: Kartik
>Priority: Minor
> Labels: camel-component
> Fix For: 3.14.10, 3.20.7, 3.21.1, 3.22.0, 4.0.0
>
>
> When we set the "{*}workerPool"{*} property in the Kafka configuration it's
> not honored and "KafkaProducer" falls back to creating a new thread pool with
> the default 10 threads.
>
> As mentioned in
> [https://camel.apache.org/components/3.14.x/kafka-component.html#_component_options]
> There is a component option to provide custom thread pool "{*}workerPool
> (producer){*}"
>
> So in KafkaProducer.java
>
> {code:java}
> // code placeholder
> @Override
> @SuppressWarnings("rawtypes")
> protected void doStart() throws Exception {
> Properties props = getProps();
> if (kafkaProducer == null) {
> createProducer(props);
> }
> // if we are in asynchronous mode we need a worker pool
> if (!configuration.isSynchronous() && workerPool == null) {
> workerPool = endpoint.createProducerExecutor();
> // we create a thread pool so we should also shut it down
> shutdownWorkerPool = true;
> }
> }
> {code}
> " _*if (!configuration.isSynchronous() && workerPool == null) {*_ "
> we only check for synchronization, since the worker pool is "null" when
> created, it goes ahead and creates a new pool with default threads by calling
> "createProducerExecutor()"
>
> Ideally, we should check if "configuration.getWorkerPool()" and if it's not
> null, we should assign this to the worker pool instead of creating the new
> one.
>
> Fix.
>
> {code:java}
> // code placeholder
> protected void doStart() throws Exception {
> Properties props = this.getProps();
> if (this.kafkaProducer == null) {
> this.createProducer(props);
> }
> if (!this.configuration.isSynchronous() && this.workerPool == null) {
> if (this.configuration.getWorkerPool() != null) {
> this.workerPool = this.configuration.getWorkerPool();
> this.shutdownWorkerPool = false;
> } else {
> this.workerPool = this.endpoint.createProducerExecutor();
> this.shutdownWorkerPool = true;
> }
> }
> } {code}
>
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (CAMEL-19729) camel-jbang - camel get route-dump should handle 2+ routes in the source files
Claus Ibsen created CAMEL-19729: --- Summary: camel-jbang - camel get route-dump should handle 2+ routes in the source files Key: CAMEL-19729 URL: https://issues.apache.org/jira/browse/CAMEL-19729 Project: Camel Issue Type: Bug Components: camel-jbang Reporter: Claus Ibsen Assignee: Claus Ibsen Fix For: 4.0.1, 4.1.0 There may be a problem if camel run foo.yaml and there are 2+ routes in the file, then it may be that route dump can only dump one of the routes. Need to investigate more. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-19518) camel-disruptor: replace Thread.sleep in tests
[ https://issues.apache.org/jira/browse/CAMEL-19518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17752473#comment-17752473 ] Nikita_Konovalov commented on CAMEL-19518: -- I'll take this one > camel-disruptor: replace Thread.sleep in tests > -- > > Key: CAMEL-19518 > URL: https://issues.apache.org/jira/browse/CAMEL-19518 > Project: Camel > Issue Type: Task > Components: camel-disruptor, tests >Affects Versions: 4.0.0 >Reporter: Otavio Rodolfo Piske >Priority: Minor > Labels: easy, help-wanted > > We have many tests which use Thread.sleep for synchronization. This is bug > prone and can introduce flakiness when running on environments with different > capacities. > Ideally we should replace these with: > * [Awaitility|http://www.awaitility.org/] > * Java's native syncronization mechanism (Latches, Phasers, Locks, etc) > * Nothing (i.e.; in some cases the sleep can simply be removed) > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-19516) camel-consul: replace Thread.sleep in tests
[ https://issues.apache.org/jira/browse/CAMEL-19516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17752406#comment-17752406 ] Nikita_Konovalov commented on CAMEL-19516: -- I'll take this one > camel-consul: replace Thread.sleep in tests > --- > > Key: CAMEL-19516 > URL: https://issues.apache.org/jira/browse/CAMEL-19516 > Project: Camel > Issue Type: Task > Components: camel-consul, tests >Affects Versions: 4.0.0 >Reporter: Otavio Rodolfo Piske >Priority: Minor > Labels: easy, help-wanted > > We have many tests which use Thread.sleep for synchronization. This is bug > prone and can introduce flakiness when running on environments with different > capacities. > Ideally we should replace these with: > * [Awaitility|http://www.awaitility.org/] > * Java's native syncronization mechanism (Latches, Phasers, Locks, etc) > * Nothing (i.e.; in some cases the sleep can simply be removed) > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (CAMEL-19561) Upgrade artemis after ARTEMIS-4338 is fixed
[ https://issues.apache.org/jira/browse/CAMEL-19561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Otavio Rodolfo Piske reassigned CAMEL-19561: Assignee: Otavio Rodolfo Piske > Upgrade artemis after ARTEMIS-4338 is fixed > --- > > Key: CAMEL-19561 > URL: https://issues.apache.org/jira/browse/CAMEL-19561 > Project: Camel > Issue Type: Task > Components: camel-stomp >Reporter: Otavio Rodolfo Piske >Assignee: Otavio Rodolfo Piske >Priority: Major > Fix For: 4.0.0 > > > There Apache Artemis issue > [ARTEMIS-4338|https://issues.apache.org/jira/browse/ARTEMIS-4338], that > happens on version 2.29, breaks camel-stomp. We should upgrade after it is > fixed. > > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-19561) Upgrade artemis after ARTEMIS-4338 is fixed
[ https://issues.apache.org/jira/browse/CAMEL-19561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17752397#comment-17752397 ] Otavio Rodolfo Piske commented on CAMEL-19561: -- [~apupier] that's a good question. I think so, but I believe we need to confirm with [~acosentino]. > Upgrade artemis after ARTEMIS-4338 is fixed > --- > > Key: CAMEL-19561 > URL: https://issues.apache.org/jira/browse/CAMEL-19561 > Project: Camel > Issue Type: Task > Components: camel-stomp >Reporter: Otavio Rodolfo Piske >Priority: Major > Fix For: 4.0.0 > > > There Apache Artemis issue > [ARTEMIS-4338|https://issues.apache.org/jira/browse/ARTEMIS-4338], that > happens on version 2.29, breaks camel-stomp. We should upgrade after it is > fixed. > > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CAMEL-19561) Upgrade artemis after ARTEMIS-4338 is fixed
[ https://issues.apache.org/jira/browse/CAMEL-19561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17752394#comment-17752394 ] Aurélien Pupier commented on CAMEL-19561: - Should it be updated in Camel Kamelet too? https://github.com/apache/camel-kamelets/blob/99834d8297d34731b1536a95312d67f69ce13d67/pom.xml#L70 > Upgrade artemis after ARTEMIS-4338 is fixed > --- > > Key: CAMEL-19561 > URL: https://issues.apache.org/jira/browse/CAMEL-19561 > Project: Camel > Issue Type: Task > Components: camel-stomp >Reporter: Otavio Rodolfo Piske >Priority: Major > Fix For: 4.0.0 > > > There Apache Artemis issue > [ARTEMIS-4338|https://issues.apache.org/jira/browse/ARTEMIS-4338], that > happens on version 2.29, breaks camel-stomp. We should upgrade after it is > fixed. > > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-19728) parquetAvro is missing in dataformats model
[ https://issues.apache.org/jira/browse/CAMEL-19728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-19728. - Resolution: Fixed > parquetAvro is missing in dataformats model > --- > > Key: CAMEL-19728 > URL: https://issues.apache.org/jira/browse/CAMEL-19728 > Project: Camel > Issue Type: Task > Components: camel-core >Reporter: Claus Ibsen >Assignee: Claus Ibsen >Priority: Major > Fix For: 4.0.0 > > > It should be added to general dataformats model - its in marshal and > unmarshal already. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (CAMEL-19728) parquetAvro is missing in dataformats model
Claus Ibsen created CAMEL-19728: --- Summary: parquetAvro is missing in dataformats model Key: CAMEL-19728 URL: https://issues.apache.org/jira/browse/CAMEL-19728 Project: Camel Issue Type: Task Components: camel-core Reporter: Claus Ibsen Assignee: Claus Ibsen Fix For: 4.0.0 It should be added to general dataformats model - its in marshal and unmarshal already. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-15903) Master component do not retry endpoint startup on failure
[ https://issues.apache.org/jira/browse/CAMEL-15903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-15903: Fix Version/s: 4.x (was: 3.x) > Master component do not retry endpoint startup on failure > - > > Key: CAMEL-15903 > URL: https://issues.apache.org/jira/browse/CAMEL-15903 > Project: Camel > Issue Type: Bug > Components: camel-master >Reporter: EDGAR CHERNICK >Priority: Minor > Fix For: 4.x > > > The cluster view implementations have a listener attribute where the master > component hooks itself to receive leadership change events. > When the app instance becomes leader the cluster view will mark that instance > as leader then it will trigger the leadershipchangedevent, this will trigger > the master component event handler and it will start the delegated consumer > and endpoint. > The issue happens when the delegated consumer or endpoint fail to start. The > exception throw by them will go up in the stack, however, this exception does > not affect the leadership, i.e., once the app instance becomes leader it will > stay so even if the delegated components fail to start. > Both KubernetesClusterView and FileLockClusterView have this issue. > KubernetesClusterView uses KubernetesLeadershipController to run the > leadership check at an interval. When it acquires the leadership it updates > the configmap with that info and call TimedLeaderNotifier refreshLeadership > method to check if the leadership has changed. The issue here is that it will > mark itself as leader before firing the leadership changed event. Another > issue is that the event is fired in a separete thread, so, when the start of > the delegated components fail the exception will "die" together with the > thread. When the next scheduled leadership check runs the app instance is > already the leader and it will not fire the leadership changed event and the > delegated component will never start. > FileLockClusterView has a similar issue, it acquires the file lock prior to > firing the event, even if the event processing fails it does not rollback the > leader selection. > Other cluster view implementations might have the same issue. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-18017) camel-as2 - Signed content in MDN gets corrupted and is not possible to validate
[
https://issues.apache.org/jira/browse/CAMEL-18017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-18017:
Fix Version/s: 3.22.0
(was: 3.x)
> camel-as2 - Signed content in MDN gets corrupted and is not possible to
> validate
>
>
> Key: CAMEL-18017
> URL: https://issues.apache.org/jira/browse/CAMEL-18017
> Project: Camel
> Issue Type: Bug
> Components: camel-as2
>Affects Versions: 3.16.0
>Reporter: Ted Lundqvist
>Priority: Minor
> Fix For: 3.22.0
>
>
> When the http response with an MDN is received it is parsed to a
> MultipartSignedEntity-object.
> When the object is serialized back to an outputstream using the method
> AS2MessageDispositionNotificationEntity#writeTo the string is not guaranteed
> to be identical to the the string received in the original http-response.
> This makes it impossible to calculate an correct message-digest and the
> method MultipartSignedEntity#isValid returns false because the following
> exception is thrown:
> "org.bouncycastle.cms.CMSSignerDigestMismatchException: message-digest
> attribute value does not match calculated value"
> when calling:
> signer.verify(new
> JcaSimpleSignerInfoVerifierBuilder().setProvider("BC").build(cert)
> I tried to use the AS2-client to send messeages to both IBM Datapower and
> ArcESB and it was not possible to validate the MDN from neither of them.
> A few examples of differences between the actual received string and the
> reconstructed string are (see the full examples further down):
> # The order of the fields in the disposition-notification was in the wrong
> order:
> In the original string they where ordered as follows:
> Reporting-UA
> Original-Recipient
> Final-Recipient
> Original-Message-ID
> Disposition
> Received-content-MIC
> But in the reconstructed string the field Original-Recipient had been moved
> down and was placed before Received-content-MIC.
> # Received-content-MIC returned from both Datapower and ArcESB had a space
> between the comma-sign and the algorithmId.
> In the reconstructed string the space-character was removed.
> According to the example in RFC4130
> ([https://datatracker.ietf.org/doc/html/rfc4130)] is seems as if it should be
> ok to have a space-character.
> # In the MDN from ArcESB the field Received-content-MIC the word content was
> written with a capital 'C' i.e. Received-Content-MIC.
> I'm not sure if that is valid according to the standard or not.
> The actual string received in the http-response:
> {code:java}
> Content-Type: multipart/report; report-type=disposition-notification;
> boundary=8e7e662d-3449-4777-96dc-7a6ba5ddbfb3
> --8e7e662d-3449-4777-96dc-7a6ba5ddbfb3
> Content-Type: text/plain; charset=us-asciiThis MDN response message is
> for:Original-Message-ID: <52vncg5lq4.1sqyji9ko4...@camel.apache.org>
> From: AMFAutoTest_AS2--8e7e662d-3449-4777-96dc-7a6ba5ddbfb3
> Content-Type: message/disposition-notificationReporting-UA: DataPower
> Original-Recipient: rfc822; "TEST"
> Final-Recipient: rfc822; "TEST"
> Original-Message-ID: <52vncg5lq4.1sqyji9ko4...@camel.apache.org>
> Disposition: automatic-action/MDN-sent-automatically; processed
> Received-content-MIC:
> vUE91/gKwRCPdosfVE3H/VQNy1xHgZ+YWoVgcM5mVBya/ggZb7KxjozNUk7ewsrHOxoI9BDY2uURCcxpKU9dYA==,
> sha-512
> --8e7e662d-3449-4777-96dc-7a6ba5ddbfb3-- {code}
> The String reconstructed from the MultipartSignedEntity:
> {code:java}
> Content-Type: multipart/report; report-type=disposition-notification;
> boundary=8e7e662d-3449-4777-96dc-7a6ba5ddbfb3
> --8e7e662d-3449-4777-96dc-7a6ba5ddbfb3
> Content-Type: text/plain; charset=us-asciiThis MDN response message is
> for:Original-Message-ID: <52vncg5lq4.1sqyji9ko4...@camel.apache.org>
> From: AMFAutoTest_AS2--8e7e662d-3449-4777-96dc-7a6ba5ddbfb3
> Content-Type: message/disposition-notificationReporting-UA: DataPower
> Final-Recipient: rfc822;"TEST"
> Original-Message-ID: <52vncg5lq4.1sqyji9ko4...@camel.apache.org>
> Disposition: automatic-action/MDN-sent-automatically;processed
> Original-Recipient: rfc822; "TEST"
> Received-content-MIC:
> vUE91/gKwRCPdosfVE3H/VQNy1xHgZ+YWoVgcM5mVBya/ggZb7KxjozNUk7ewsrHOxoI9BDY2uURCcxpKU9dYA==,sha-512
> --8e7e662d-3449-4777-96dc-7a6ba5ddbfb3-- {code}
> In order to always being able to calculate a correct digest the original
> string that was signed should be preserved as is.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-17110) Camel-Kamelets: While using AWS S3 source noticed files were deleted before being consumed at all
[
https://issues.apache.org/jira/browse/CAMEL-17110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-17110:
Fix Version/s: 4.x
(was: 3.x)
> Camel-Kamelets: While using AWS S3 source noticed files were deleted before
> being consumed at all
> -
>
> Key: CAMEL-17110
> URL: https://issues.apache.org/jira/browse/CAMEL-17110
> Project: Camel
> Issue Type: Bug
> Components: camel-aws
>Affects Versions: 3.11.3
>Reporter: Andrea Cosentino
>Assignee: Andrea Cosentino
>Priority: Major
> Fix For: 4.x
>
>
> {code}
> - route:
> from:
> uri: "kamelet:aws-s3-source"
> parameters:
> bucketNameOrArn: "camel-kafka-connector"
> accessKey: "access"
> secretKey: "secret"
> region: "eu-west-1"
> steps:
> - to:
> uri: "kamelet:kafka-not-secured-sink"
> parameters:
> brokers: "localhost:9092"
> topic: "s3-source-topic"
> {code}
> In the log, if you enabled trace you may notice something like:
> {code:java}
> 10:14:24.476 [Camel (AWS-S3-To-Kafka) thread #11 -
> KafkaProducer[s3-source-topic]] TRACE o.a.c.c.aws2.s3.AWS2S3Consumer -
> Deleted object from bucket camel-kafka-connector with key
> jkXzIEbaYyKMTMwGpNHL.txt...
> 10:14:24.491 [Camel (AWS-S3-To-Kafka) thread #0 -
> aws2-s3://camel-kafka-connector] TRACE s.a.awssdk.auth.signer.Aws4Signer -
> AWS4 Canonical Request: GET
> /jkXzIEbaYyKMTMwGpNHL.txt
> 10:14:24.582 [Camel (AWS-S3-To-Kafka) thread #0 -
> aws2-s3://camel-kafka-connector] DEBUG software.amazon.awssdk.request -
> Received error response:
> software.amazon.awssdk.services.s3.model.NoSuchKeyException: The specified
> key does not exist.
> {code}
> While, the get should happens before the deletions. This is happening only
> when using Kamelets. It looks like the exchange completed before the get
> operation has been done.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-18917) camel-as2 - Signature is not validated
[ https://issues.apache.org/jira/browse/CAMEL-18917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-18917: Fix Version/s: 3.22.0 (was: 3.x) > camel-as2 - Signature is not validated > -- > > Key: CAMEL-18917 > URL: https://issues.apache.org/jira/browse/CAMEL-18917 > Project: Camel > Issue Type: Improvement > Components: camel-as2 >Reporter: dennis lucero >Priority: Minor > Fix For: 3.22.0 > > > org.apache.camel.component.as2.api.entity.EntityParser can parse SIGNED > requests into org.apache.camel.component.as2.api.entity.MultipartSignedEntity. > But the signature part is completely ignored and never validated. > Is this intentional? Whats the point of having a signature that is never > validated. > I'm wondering, because MultipartSignedEntity has a method "isValid" that is > only used in the unit tests, not during request handling. > Also I've recognized, that the "isValid" method does the validation wrong. > To my knowledge one should check if the signatures certificate is contained > in the certificates configured on the endpoint and then verify the signature > against this. But in fact, the method validates the request-signature against > the certificate provided within the signature. So currently the signature > would be always valid. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-17719) camel-salesforce: allow to retrieve CDC json schema from meta service
[
https://issues.apache.org/jira/browse/CAMEL-17719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-17719:
Fix Version/s: 3.22.0
(was: 3.x)
> camel-salesforce: allow to retrieve CDC json schema from meta service
> -
>
> Key: CAMEL-17719
> URL: https://issues.apache.org/jira/browse/CAMEL-17719
> Project: Camel
> Issue Type: New Feature
> Components: camel-salesforce
>Reporter: Luca Burgazzoli
>Assignee: Jeremy Ross
>Priority: Minor
> Fix For: 3.22.0
>
>
> To get the full schema of a change event message, it it possible to make a
> GET request to the REST API that includes the schema ID sent in the event
> message, as example:
> {code}
> /vXX.X/event/eventSchema/
> {code}
> or by using the event name:
> {code}
> /vXX.X/sobjects//eventSchema
> {code}
> It would be nice if the meta data extension would be able to return the json
> schema of the
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-19481) Upgrade to Jetty 10
[ https://issues.apache.org/jira/browse/CAMEL-19481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-19481: Fix Version/s: 3.22.0 (was: 3.x) > Upgrade to Jetty 10 > --- > > Key: CAMEL-19481 > URL: https://issues.apache.org/jira/browse/CAMEL-19481 > Project: Camel > Issue Type: Dependency upgrade >Reporter: Nicolas Filotto >Assignee: Nicolas Filotto >Priority: Minor > Fix For: 3.22.0 > > > Jetty 9 has reached its EOL see > https://github.com/eclipse/jetty.project/issues/7958, thus we need to upgrade > to at least Jetty 10 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-18277) Google Pubsub: MessageOrderingIT test does not work with real account
[
https://issues.apache.org/jira/browse/CAMEL-18277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-18277:
Fix Version/s: Future
(was: 3.x)
> Google Pubsub: MessageOrderingIT test does not work with real account
> -
>
> Key: CAMEL-18277
> URL: https://issues.apache.org/jira/browse/CAMEL-18277
> Project: Camel
> Issue Type: Bug
> Components: camel-google-pubsub, tests
>Affects Versions: 3.18.0
>Reporter: Jiri Ondrusek
>Assignee: Jiri Ondrusek
>Priority: Minor
> Fix For: Future
>
>
> I'm working on test coverage of _camel-pubsub_ extension in Camel-quarkus
> ([issue|[https://github.com/apache/camel-quarkus/issues/3910]).]
> I noticed:
> * There is no easy way of running integration tests with the real account.
> It would be nice to have an option to export for example a several env.
> properties (like export GOOGLE_APPLICATION_CREDENTIALS=.. and export
> GOOGLE_PROJECT_ID=...) and allow execution of the tests with the real account.
> * _MessageOrderingIT_ does not work with the real cloud account. You can see
> an exception, which is probably caused by the use of regional endpoint.
> {code:java}
> java.util.concurrent.ExecutionException:
> com.google.api.gax.rpc.UnauthenticatedException:
> io.grpc.StatusRuntimeException: UNAUTHENTICATED: Request had invalid
> authentication credentials. Expected OAuth 2 access token, login cookie or
> other valid authentication credential. See
> https://developers.google.com/identity/sign-in/web/devconsole-project.
> at
> com.google.common.util.concurrent.AbstractFuture.getDoneValue(AbstractFuture.java:588)
> at
> com.google.common.util.concurrent.AbstractFuture.get(AbstractFuture.java:567)
> at com.google.api.core.AbstractApiFuture.get(AbstractApiFuture.java:55)
> at
> org.apache.camel.component.google.pubsub.GooglePubsubProducer.send(GooglePubsubProducer.java:117)
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CAMEL-6543) provide a way to expose common header names, types and payload types for endpoints
[ https://issues.apache.org/jira/browse/CAMEL-6543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-6543. Resolution: Delivered lets close this old ticket - Thanks James for giving us Apache Camel > provide a way to expose common header names, types and payload types for > endpoints > -- > > Key: CAMEL-6543 > URL: https://issues.apache.org/jira/browse/CAMEL-6543 > Project: Camel > Issue Type: New Feature >Reporter: James Strachan >Priority: Major > Fix For: 3.x > > > Given a configuration of an Endpoint, it'd be nice if there was a way for > endpoints to expose what a consumer will receive up front (at design time, > before it actually runs), in terms of headers (their name & types) and the > payload type. > Most of this is documented on the wiki in places already - its useful stuff > to konw; but there's no way to introspect an endpoint and know this (so we > can, for example, visualise the things exposed by an endpoint - or provide > better validation of what can connect to what, what will work or fail; what > type conversions could be done after consuming from an endpoint, what headers > are available by default in expression languages and so forth. > I guess other steps in a camel flow can change this data too (e.g. > adding/removing headers, changing the payload value). > But as a start - and endpoint consumer specific plugin would be great. > e.g. maybe we can add a new method to ComponentConfiguration which allows > endpoints to return the header/payload metadata (if its known) > https://cwiki.apache.org/confluence/display/CAMEL/ComponentConfiguration > We could maybe add some annotations, metadata or code which could then be > introspected by the generated endpoint documentation: > https://cwiki.apache.org/confluence/display/CAMEL/Endpoint+Annotations > afterall we often define constants for the header values already for a > component; so it would be easy to add an annotation and have them discovered; > its mostly just being able to find all the headers exposed by default (and > which are optional I guess) on messages from an endpoint. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-8306) rest-dsl - Add support for wildcards to match on prefix
[
https://issues.apache.org/jira/browse/CAMEL-8306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-8306:
---
Fix Version/s: 4.x
(was: 3.x)
> rest-dsl - Add support for wildcards to match on prefix
> ---
>
> Key: CAMEL-8306
> URL: https://issues.apache.org/jira/browse/CAMEL-8306
> Project: Camel
> Issue Type: Improvement
> Components: camel-core, rest
>Reporter: Claus Ibsen
>Priority: Major
> Fix For: 4.x
>
>
> See SO
> http://stackoverflow.com/questions/28264748/regex-on-camel-rest-component
> eg if we add support for using * as a wildcard then people can do rest paths
> with * as suffix, to indicate that it should match by wildcard
> eg
> rest("/api/user/*")
> To match
> - /api/user
> - /api/user/foo
> -/api/user/foo/bar
> As * requires support from the underlying component, but most of them support
> that too, eg servlet / jetty / netty-http etc so likely we should be able to
> do this
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (CAMEL-9547) bean - Allow use of Java8 method reference in Camel route
[ https://issues.apache.org/jira/browse/CAMEL-9547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-9547. Resolution: Won't Fix > bean - Allow use of Java8 method reference in Camel route > - > > Key: CAMEL-9547 > URL: https://issues.apache.org/jira/browse/CAMEL-9547 > Project: Camel > Issue Type: New Feature > Components: camel-core >Reporter: Geert Schuring >Priority: Minor > Fix For: 3.x > > > Camel allows for a route to call a bean by pointing to a class and supplying > the name of the method as a string. This does not allow IDE's to easily point > out problems of the mentioned class does not have a method with that name. > It would be very nice of we could have Camel call a certain method by > supplying a Java8 method reference. > https://docs.oracle.com/javase/tutorial/java/javaOO/methodreferences.html -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-11132) Provide type metadata for each Components/DataFormats
[ https://issues.apache.org/jira/browse/CAMEL-11132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-11132: Fix Version/s: 4.x (was: 3.x) > Provide type metadata for each Components/DataFormats > - > > Key: CAMEL-11132 > URL: https://issues.apache.org/jira/browse/CAMEL-11132 > Project: Camel > Issue Type: New Feature > Components: camel-core >Reporter: Tomohisa Igarashi >Assignee: Tomohisa Igarashi >Priority: Major > Fix For: 4.x > > > CAMEL-10447 has introduced InputType/OutputType declaration and declarative > Transformer/Validator based on those types declared on a route. > Next step is to provide type metadata for each Components/DataFormats: > * Let components/DataFormats provide metadata about what data types are > supported so that app developer can see > * Narrow down the possible data types (i.e. exclude unsupported types) and > transformers when writing a route in IDE, allow IDE to show those candidates > as a hint so that app developer can choose from. Also maven plugin could > leverage those metadata > * Provide such facility from camel side so that the maven plugin and/or IDE > can leverage it > Annotation would be an option, but it only provides static types. For example > xslt component only consumes/produces XML so "XML" could be provided via > annotation. But dozer component consumes/produces arbitrary data formats and > the actual type to be used is determined via configuration, so it cannot be > provided via annotation. It would need a common way to calculate possible > input types and output types on a component/endpoint and dataformat from its > configuration. > Sometimes even body of the input message would affect the possible output > types. To visualize this we'll need some kind of simulation with a test > message. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-11114) Create cache DSL
[
https://issues.apache.org/jira/browse/CAMEL-4?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-4:
Fix Version/s: Future
(was: 3.x)
> Create cache DSL
>
>
> Key: CAMEL-4
> URL: https://issues.apache.org/jira/browse/CAMEL-4
> Project: Camel
> Issue Type: New Feature
> Components: camel-core, eip
>Reporter: Nicola Ferraro
>Priority: Major
> Fix For: Future
>
>
> We should evaluate adding a new "cache" dsl that can be used with all cache
> components in Camel. A default implementation may use also caffeine, included
> in camel-core.
> A possible usage example may be:
> {code}
> from("xxx")
> .cache().on("${header.yyy}").ttl(60) // caches the body
>
> .to("http4://a-service-that-makes-me-pay-for-each-request.com/api/expensive-endpoint")
> .transform().zzz()
>
> .to("http4://or-a-service-that-i-can-call-few-times-a-day.com/api/limited-endpoint")
> .unmarshal()
> .endCache()
> {code}
> It should be also useful to protect internal services when using Camel e.g.
> as a api-gateway (almost what hystrix does in case of failure of the target
> host).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-11246) camel-catalog : provide information about the uri support for expressions
[ https://issues.apache.org/jira/browse/CAMEL-11246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-11246: Fix Version/s: 4.x (was: 3.x) > camel-catalog : provide information about the uri support for expressions > - > > Key: CAMEL-11246 > URL: https://issues.apache.org/jira/browse/CAMEL-11246 > Project: Camel > Issue Type: Improvement > Components: tooling >Reporter: Luca Burgazzoli >Assignee: Claus Ibsen >Priority: Minor > Fix For: 4.x > > > Some component like camel-sql support expressions to be used inside the uri > definition and this may cause troubles in environment like spring as the > simple language prefix/suffix clash with spring's property resolution. > By providing some information about what languages the endpoint supports in > the camel-catalog, tools like IDEs or validation plugins can provide some > hints or warning to the user/developer. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-9324) camel-file - Changed read-lock to keep state between polls to allow to be faster
[ https://issues.apache.org/jira/browse/CAMEL-9324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-9324: --- Fix Version/s: 4.x (was: 3.x) > camel-file - Changed read-lock to keep state between polls to allow to be > faster > > > Key: CAMEL-9324 > URL: https://issues.apache.org/jira/browse/CAMEL-9324 > Project: Camel > Issue Type: Improvement > Components: camel-core, camel-ftp >Reporter: Claus Ibsen >Priority: Major > Fix For: 4.x > > > See nabble > http://camel.465427.n5.nabble.com/sftp-endpoint-is-not-as-performant-as-expected-tp5773654p5773879.html > Yeah the current changed read-lock afair don't keep state between > polls. So we could look into one that does that, and do a full scan of > all the files, and then do a change detect on all files all together > and make up which ones hasn't changed. And that way can react faster > than currently. > Now that may require doing more file directory listings to gather all > those files and their timestamps / size to see which one has changed, > instead of monitoring a single file one by one. Also it may mean that > files can be processed out of order, if a file sort isn't must be > strictly followed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-12866) camel-restdsl-swagger-plugin - Include api-properties from swagger file
[
https://issues.apache.org/jira/browse/CAMEL-12866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-12866:
Fix Version/s: 4.x
(was: 3.x)
> camel-restdsl-swagger-plugin - Include api-properties from swagger file
> ---
>
> Key: CAMEL-12866
> URL: https://issues.apache.org/jira/browse/CAMEL-12866
> Project: Camel
> Issue Type: Improvement
> Components: tooling
>Affects Versions: 2.22.1
>Reporter: Jochen Cordes
>Priority: Minor
> Labels: help-wanted
> Fix For: 4.x
>
>
> The camel-restdsl-swagger-plugin should include additional meta-information
> from an OpenAPI/Swagger definition and add them to the generated code, f.e.
> from the following blocks (info, license, tags) :
> "info":{
> "description":"A description",
> "version":"1.0.0",
> "title":"A title",
> "termsOfService":"http://myhost.com/terms/";,
> "contact":{
> "email":"apit...@myhost.com"
> },
> "license":{
> "name":"Apache 2.0",
> "url":"http://www.apache.org/licenses/LICENSE-2.0.html";
> }
> },
> "tags":[]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-12953) Camel grpc component doesn't transfer the Message headers
[ https://issues.apache.org/jira/browse/CAMEL-12953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-12953: Fix Version/s: Future (was: 3.x) > Camel grpc component doesn't transfer the Message headers > - > > Key: CAMEL-12953 > URL: https://issues.apache.org/jira/browse/CAMEL-12953 > Project: Camel > Issue Type: New Feature > Components: camel-grpc >Affects Versions: 2.22.1 >Reporter: Vishal Vijayan >Priority: Minor > Labels: help-wanted > Fix For: Future > > > Headers that are added to the Message in the camel Exchange before making a > call to the camel-grpc component are not received at the grpc consumer. The > expectation is that these headers would be added to the grpcStub before > sending over the wire (like other components like http4 etc). > Our team has come up with a workaround for this but it is extremely > cumbersome. We had to extend the GrpcProducer to introduce a custom > GrpcExchangeForwarder that would copy header from exchange to the stub before > invoking the sync/async method. > At the consumer side we had to extend the GrpcConsumer to use a custom > ServerInterceptor to capture the grpc headers and custom MethodHandler to > transfer the grpc headers to the Camel exchange headers. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-13188) java.io.IOException: Stream closed with mongodb3 when no data in findOneByQuery
[
https://issues.apache.org/jira/browse/CAMEL-13188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-13188:
Fix Version/s: 4.x
(was: 3.x)
> java.io.IOException: Stream closed with mongodb3 when no data in
> findOneByQuery
> ---
>
> Key: CAMEL-13188
> URL: https://issues.apache.org/jira/browse/CAMEL-13188
> Project: Camel
> Issue Type: Improvement
> Components: camel-mongodb3
>Affects Versions: 2.23.0
>Reporter: Carl-Philipp Harmant
>Priority: Minor
> Fix For: 4.x
>
>
> When doing something like:
> {noformat}
> from("direct:my-endpoint")
>
> .to("mongodb3:cosmosdb?database=dbname&collection=collname&operation=findOneByQuery"){noformat}
> The code works fine if something is found in the db. If no result is returned
> from the query, I obtain a stacktrace like that:
> {noformat}
> org.apache.camel.RuntimeCamelException: java.io.IOException: Stream closed
> at
> org.apache.camel.http.common.HttpMessage.createBody(HttpMessage.java:80)
> at org.apache.camel.impl.MessageSupport.getBody(MessageSupport.java:54)
> at
> org.apache.camel.processor.RestBindingAdvice.marshal(RestBindingAdvice.java:402)
> at
> org.apache.camel.processor.RestBindingAdvice.after(RestBindingAdvice.java:151)
> at
> org.apache.camel.processor.RestBindingAdvice.after(RestBindingAdvice.java:51)
> at
> org.apache.camel.processor.CamelInternalProcessor$InternalCallback.done(CamelInternalProcessor.java:251)
> at org.apache.camel.processor.Pipeline.process(Pipeline.java:127)
> at
> org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:201)
> at
> org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:97)
> at
> org.apache.camel.http.common.CamelServlet.doService(CamelServlet.java:213)
> at org.apache.camel.http.common.CamelServlet.service(CamelServlet.java:79)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:750)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
> at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:53)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
> at
> org.springframework.web.filter.RequestContextFilter.doFilterInternal(RequestContextFilter.java:99)
> at
> org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
> at
> org.springframework.web.filter.FormContentFilter.doFilterInternal(FormContentFilter.java:92)
> at
> org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
> at
> org.springframework.web.filter.HiddenHttpMethodFilter.doFilterInternal(HiddenHttpMethodFilter.java:93)
> at
> org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
> at
> org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal(CharacterEncodingFilter.java:200)
> at
> org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:199)
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:96)
> at
> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:490)
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:139)
> at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:92)
> at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineVal
[jira] [Updated] (CAMEL-12981) camel-catalog: provide information about active/passive endpoints
[ https://issues.apache.org/jira/browse/CAMEL-12981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-12981: Fix Version/s: Future (was: 3.x) > camel-catalog: provide information about active/passive endpoints > - > > Key: CAMEL-12981 > URL: https://issues.apache.org/jira/browse/CAMEL-12981 > Project: Camel > Issue Type: Task > Components: camel-core, tooling >Reporter: Nicola Ferraro >Priority: Major > Fix For: Future > > > In Camel K we need to distinguish active from passive endpoints in order to > determine when a integration can be scaled down to 0. > > E.g. > * a "timer" (start) endpoint is *active*, because it needs to have a JVM > always running and do something at each interval > * a "jms" (start) endpoint is *active* because it needs to establish a > connection to the broker and keep it alive > * a "direct" or "seda" endpoint is *passive*, because they do something when > they receive an exchange from another route > * a "undertow" (start) endpoint is *passive*, because it does nothing until > somebody calls it from an +external+ service (http based endpoints can all be > considered passive in Knative+CamelK) > > We should add this information to the catalog. Now I've embedded it in Camel > K. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-13488) camel-infinispan support counters
[ https://issues.apache.org/jira/browse/CAMEL-13488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-13488: Fix Version/s: 4.x (was: 3.x) > camel-infinispan support counters > - > > Key: CAMEL-13488 > URL: https://issues.apache.org/jira/browse/CAMEL-13488 > Project: Camel > Issue Type: Improvement > Components: camel-infinispan >Reporter: Luca Burgazzoli >Assignee: Andrea Cosentino >Priority: Minor > Fix For: 4.x > > > We should support operations against infinispan counters, see > https://github.com/infinispan/infinispan/blob/master/documentation/src/main/asciidoc/user_guide/counters.adoc -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-13909) Camel Rest-DSL doesn't generate type & outType from openapi 2.0 file
[
https://issues.apache.org/jira/browse/CAMEL-13909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-13909:
Fix Version/s: 4.x
(was: 3.x)
> Camel Rest-DSL doesn't generate type & outType from openapi 2.0 file
>
>
> Key: CAMEL-13909
> URL: https://issues.apache.org/jira/browse/CAMEL-13909
> Project: Camel
> Issue Type: Improvement
> Components: rest, tooling
>Reporter: Hari Rao
>Priority: Major
> Fix For: 4.x
>
>
> In the camel-swagger-rest-dsl-generator project, it is not generating .type &
> .outType rest dsl though available as part of openapi 2.0 (swagger) spec.
> This is because in (as far as I investigated) in
> org.apache.camel.generator.swagger.OperationVisitor class we have the
> following code and beyond we do not have options to emit type & outType.
> Besides in the method, it is also not possible to pass User defined objects
> which will help to create those models.
> {code:java}
> void visit(final HttpMethod method, final Operation operation) {
> if (filter.accept(operation.getOperationId())) {
> final String methodName = method.name().toLowerCase();
> emitter.emit(methodName, path);
> emit("id", operation.getOperationId());
> emit("description", operation.getDescription());
> emit("consumes", operation.getConsumes());
> emit("produces", operation.getProduces());{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-14470) Camel-github: Switch from egit to kohsuke github-api
[ https://issues.apache.org/jira/browse/CAMEL-14470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-14470: Fix Version/s: 4.x (was: 3.x) > Camel-github: Switch from egit to kohsuke github-api > - > > Key: CAMEL-14470 > URL: https://issues.apache.org/jira/browse/CAMEL-14470 > Project: Camel > Issue Type: Improvement > Components: camel-github >Reporter: Andrea Cosentino >Assignee: Andrea Cosentino >Priority: Major > Fix For: 4.x > > > Egit is not updated from a while, at least the version in mylyn. The > github-api from kohsuke is actually the best Java client out there. So > probably it makes sense to switch. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-14880) Create a camel-couchdb3 component
[ https://issues.apache.org/jira/browse/CAMEL-14880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-14880: Fix Version/s: Future (was: 3.x) > Create a camel-couchdb3 component > - > > Key: CAMEL-14880 > URL: https://issues.apache.org/jira/browse/CAMEL-14880 > Project: Camel > Issue Type: New Feature >Affects Versions: 3.2.0 >Reporter: Alex Dettinger >Priority: Minor > Fix For: Future > > > As per the context of > [CAMEL-14822|https://issues.apache.org/jira/browse/CAMEL-14822], the > camel-couchdb component is exposed to the de-facto end of life of the > underlying couchdb library. As such, camel currently offers no support to > couchdb 3.x. > A way of dealing with such situation would be to create a camel-couchdb3 > component on top of [java-cloudant|https://github.com/cloudant/java-cloudant]. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-15211) camel-main - Allow to configure SSL context parameters
[ https://issues.apache.org/jira/browse/CAMEL-15211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-15211: Fix Version/s: 4.x (was: 3.x) > camel-main - Allow to configure SSL context parameters > -- > > Key: CAMEL-15211 > URL: https://issues.apache.org/jira/browse/CAMEL-15211 > Project: Camel > Issue Type: Improvement > Components: camel-main >Reporter: Claus Ibsen >Priority: Major > Fix For: 4.x > > > Would be great if we can make configuring Camels SSL security parameters via > camel.main.ssl. parameters. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-14949) Support OAuth in Slack component
[ https://issues.apache.org/jira/browse/CAMEL-14949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-14949: Fix Version/s: Future (was: 3.x) > Support OAuth in Slack component > > > Key: CAMEL-14949 > URL: https://issues.apache.org/jira/browse/CAMEL-14949 > Project: Camel > Issue Type: Improvement > Components: camel-slack >Affects Versions: 3.2.0, 2.25.1 >Reporter: Zoran Regvart >Assignee: Andrea Cosentino >Priority: Major > Fix For: Future > > > Slack is deprecating the ["legacy" token > authentication|https://api.slack.com/legacy/custom-integrations/legacy-tokens]. > We should migrate from that to [OAuth|https://api.slack.com/legacy/oauth] > for authentication. Note there are several [types of > tokens|https://api.slack.com/authentication/token-types] at Slack. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-14949) Support OAuth in Slack component
[ https://issues.apache.org/jira/browse/CAMEL-14949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-14949: Priority: Minor (was: Major) > Support OAuth in Slack component > > > Key: CAMEL-14949 > URL: https://issues.apache.org/jira/browse/CAMEL-14949 > Project: Camel > Issue Type: Improvement > Components: camel-slack >Affects Versions: 3.2.0, 2.25.1 >Reporter: Zoran Regvart >Assignee: Andrea Cosentino >Priority: Minor > Fix For: Future > > > Slack is deprecating the ["legacy" token > authentication|https://api.slack.com/legacy/custom-integrations/legacy-tokens]. > We should migrate from that to [OAuth|https://api.slack.com/legacy/oauth] > for authentication. Note there are several [types of > tokens|https://api.slack.com/authentication/token-types] at Slack. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-15226) Cleanup and refactore Camel Karaf
[ https://issues.apache.org/jira/browse/CAMEL-15226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-15226. - Resolution: Later > Cleanup and refactore Camel Karaf > - > > Key: CAMEL-15226 > URL: https://issues.apache.org/jira/browse/CAMEL-15226 > Project: Camel > Issue Type: Task > Components: karaf >Reporter: Jean-Baptiste Onofré >Assignee: Jean-Baptiste Onofré >Priority: Minor > Fix For: 3.x > > > Now that camel-karaf is its own repo, we can do a cleanup and better shape. > I'm working on it. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-15672) Camel-AWS2-Translate: Support batch translation job
[ https://issues.apache.org/jira/browse/CAMEL-15672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-15672. - Resolution: Won't Fix > 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] [Updated] (CAMEL-15523) Camel-Influxdb: Add testcontainers tests
[ https://issues.apache.org/jira/browse/CAMEL-15523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-15523: Fix Version/s: 4.x (was: 3.x) > Camel-Influxdb: Add testcontainers tests > > > Key: CAMEL-15523 > URL: https://issues.apache.org/jira/browse/CAMEL-15523 > Project: Camel > Issue Type: Task > Components: camel-influxdb >Reporter: Andrea Cosentino >Priority: Minor > Fix For: 4.x > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-15252) Google Pubsub Component manual acknowledgement mode
[ https://issues.apache.org/jira/browse/CAMEL-15252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-15252: Fix Version/s: 4.x (was: 3.x) > Google Pubsub Component manual acknowledgement mode > --- > > Key: CAMEL-15252 > URL: https://issues.apache.org/jira/browse/CAMEL-15252 > Project: Camel > Issue Type: New Feature > Components: camel-google-pubsub >Affects Versions: 3.4.0 >Reporter: Ramesh Venkitaswaran >Priority: Major > Fix For: 4.x > > > The camel documentation states that there are two ways to acknowledge a > Google pubsub message. They are "ackMode=AUTO" and "ackMode=NONE". If the > mode is set to NONE, the document states that the "downstream process has to > acknowledge explicitly". However there are no examples, or pointers on how to > do that. > The unit tests also do not reflect this scenario. The > [AckModeNoneTest.java|https://github.com/apache/camel/blob/master/components/camel-google-pubsub/src/test/java/org/apache/camel/component/google/pubsub/integration/AckModeNoneTest.java] > sets the ackMode to NONE, and checks if the message is redelivered, but it > doesn't test how to acknowledge the message. This file > [AcknowledgeSync.java|https://github.com/apache/camel/blob/master/components/camel-google-pubsub/src/main/java/org/apache/camel/component/google/pubsub/consumer/AcknowledgeSync.java] > has the steps to acknowledge, but it's not clear how to do that within a > Camel route. It seems to need an class called > com.google.cloud.pubsub.v1.stub.SubscriberStub that is passed into it. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-15252) Google Pubsub Component manual acknowledgement mode
[ https://issues.apache.org/jira/browse/CAMEL-15252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-15252: Priority: Minor (was: Major) > Google Pubsub Component manual acknowledgement mode > --- > > Key: CAMEL-15252 > URL: https://issues.apache.org/jira/browse/CAMEL-15252 > Project: Camel > Issue Type: New Feature > Components: camel-google-pubsub >Affects Versions: 3.4.0 >Reporter: Ramesh Venkitaswaran >Priority: Minor > Fix For: 4.x > > > The camel documentation states that there are two ways to acknowledge a > Google pubsub message. They are "ackMode=AUTO" and "ackMode=NONE". If the > mode is set to NONE, the document states that the "downstream process has to > acknowledge explicitly". However there are no examples, or pointers on how to > do that. > The unit tests also do not reflect this scenario. The > [AckModeNoneTest.java|https://github.com/apache/camel/blob/master/components/camel-google-pubsub/src/test/java/org/apache/camel/component/google/pubsub/integration/AckModeNoneTest.java] > sets the ackMode to NONE, and checks if the message is redelivered, but it > doesn't test how to acknowledge the message. This file > [AcknowledgeSync.java|https://github.com/apache/camel/blob/master/components/camel-google-pubsub/src/main/java/org/apache/camel/component/google/pubsub/consumer/AcknowledgeSync.java] > has the steps to acknowledge, but it's not clear how to do that within a > Camel route. It seems to need an class called > com.google.cloud.pubsub.v1.stub.SubscriberStub that is passed into it. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-16073) camel-pulsar - If consumer failed then it should NACK
[ https://issues.apache.org/jira/browse/CAMEL-16073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-16073: Fix Version/s: 4.x (was: 3.x) > camel-pulsar - If consumer failed then it should NACK > - > > Key: CAMEL-16073 > URL: https://issues.apache.org/jira/browse/CAMEL-16073 > Project: Camel > Issue Type: Improvement > Components: camel-pulsar >Reporter: Claus Ibsen >Priority: Minor > Fix For: 4.x > > > We should use negativeAck if exchange has exception after processing. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-16099) camel-core - Throttler EIP to support max inflight messages without time period
[ https://issues.apache.org/jira/browse/CAMEL-16099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-16099: Fix Version/s: Future (was: 3.x) > camel-core - Throttler EIP to support max inflight messages without time > period > --- > > Key: CAMEL-16099 > URL: https://issues.apache.org/jira/browse/CAMEL-16099 > Project: Camel > Issue Type: New Feature > Components: camel-core, eip >Reporter: Claus Ibsen >Priority: Major > Fix For: Future > > > The throttler EIP > https://camel.apache.org/components/latest/eips/throttle-eip.html > Is throttling based on a time window, eg max 100 messages per 10 seconds. > So if you have 99 messages in the 1st send, and 1 message in the 3d second, > and then it would be idle for 7 seconds, before a new window open up. > Instead it would be good to throttle on "concurrent requests", eg inflight > count. > So you can say max 10 inflight messsages (no time period). -- 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: Fix Version/s: Future (was: 3.x) > 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: Future > > > 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-16147) @InvokeOnHeader - Add description so we can document the method
[ https://issues.apache.org/jira/browse/CAMEL-16147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-16147: Fix Version/s: 4.x (was: 3.x) > @InvokeOnHeader - Add description so we can document the method > --- > > Key: CAMEL-16147 > URL: https://issues.apache.org/jira/browse/CAMEL-16147 > Project: Camel > Issue Type: Improvement > Components: camel-core >Reporter: Claus Ibsen >Priority: Major > Fix For: 4.x > > > Add description attribute for documentation, which the tooling can grab and > use for metadata generation, so we can store this information in the > component json file, so we now know about those header keys and > documentation. We can then generate this in the adoc doc files. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-15966) Create a Snowflake component
[ https://issues.apache.org/jira/browse/CAMEL-15966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-15966: Fix Version/s: Future (was: 3.x) > Create a Snowflake component > > > Key: CAMEL-15966 > URL: https://issues.apache.org/jira/browse/CAMEL-15966 > Project: Camel > Issue Type: New Feature >Reporter: Luca Burgazzoli >Assignee: Zheng Feng >Priority: Major > Fix For: Future > > -- 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: Fix Version/s: Future (was: 3.x) > 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: Future > > > 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] [Updated] (CAMEL-16306) Correlate by property in SJMS component
[
https://issues.apache.org/jira/browse/CAMEL-16306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-16306:
Fix Version/s: Future
(was: 3.x)
> Correlate by property in SJMS component
> ---
>
> Key: CAMEL-16306
> URL: https://issues.apache.org/jira/browse/CAMEL-16306
> Project: Camel
> Issue Type: New Feature
> Components: camel-sjms
>Affects Versions: 3.7.2
>Reporter: Raymond
>Priority: Minor
> Fix For: Future
>
>
> In the current SJMS implementation the docs says:
>
> "Currently the only correlation strategy is to use the {{JMSCorrelationId}}."
>
> I would like to correlate by property just as the JMS component has
> (*correlationProperty* ). or by JMSMessageId
> (*UseJMSMessageIDAsCorrelationId*).
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-16364) Camel-tracing: Add more decorators
[ https://issues.apache.org/jira/browse/CAMEL-16364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-16364: Fix Version/s: 4.x (was: 3.x) > Camel-tracing: Add more decorators > -- > > Key: CAMEL-16364 > URL: https://issues.apache.org/jira/browse/CAMEL-16364 > Project: Camel > Issue Type: Task > Components: camel-tracing >Reporter: Andrea Cosentino >Assignee: Andrea Cosentino >Priority: Major > Fix For: 4.x > > > We are missing a lot of components as decorators. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-16403) camel-core - URI parsing sensitive keys
[ https://issues.apache.org/jira/browse/CAMEL-16403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-16403: Fix Version/s: 4.x (was: 3.x) > camel-core - URI parsing sensitive keys > --- > > Key: CAMEL-16403 > URL: https://issues.apache.org/jira/browse/CAMEL-16403 > Project: Camel > Issue Type: Improvement > Components: camel-core >Reporter: Claus Ibsen >Priority: Major > Fix For: 4.x > > > With SensitiveUtils we know have a full list of known property names that are > sensitive. > We can use this in endpoint uri parsing to know that its value should be used > as-is (eg like it was RAW( )) > Thought with RAW() there is still some decoding due to URI invalid chars, eg > you can't have special chars in the uri, so they get decimal encoded. > Another approach: We could also just generate a random uuid as placeholder > for the value, which is backed in some internal registry/vault which then is > used to lookup the actual value, when in use. > However the uri may be used to call external service, like a http / ftp with > username:password combination, so you may want an uri representation with the > actual value. Likewise if there is some api tokens in the uri. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-16187) camel-restdsl-openapi-plugin - generate operationId enumeration
[
https://issues.apache.org/jira/browse/CAMEL-16187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-16187:
Fix Version/s: 4.x
(was: 3.x)
> camel-restdsl-openapi-plugin - generate operationId enumeration
> ---
>
> Key: CAMEL-16187
> URL: https://issues.apache.org/jira/browse/CAMEL-16187
> Project: Camel
> Issue Type: Improvement
> Components: tooling
>Affects Versions: 3.7.2
>Reporter: Vladimír Váša
>Priority: Minor
> Fix For: 4.x
>
>
> Hi,
> I discovered this great tool (camel-restdsl-openapi-plugin) two days ago.
> It's almost perfect. I have only one suggestion for improvement:
>
> Actually the plugin is generating "controller" like class with code similar
> to:
> {code:java}
> rest()
> .get("/somepath")
> .id("operationIdFromOpenAPI")
> .produces("application/json")
> .to("direct:operationIdFromOpenAPI");
> {code}
> And "user" can continue route with:
> {code:java}
> from(direct:operationIdFromOpenAPI)...
> {code}
>
> Problem:
> The problem occurs during the change operationId in next version of OpenAPI
> definition. It have to be manually checked.
>
> Improvement:
> It would be very nice if the plugin generated an enum of operationIds from
> the OpenAPI definition. Something like:
> {code:java}
> public enum ApiOperation {
> OPERATION_ID_1("operationId1"),
> ANOTHER_OPERATION_ID("anotherOperationId");
> private final String value;
> // ... constructor, toString...{code}
>
> And route with:
> {code:java}
> ...to("direct:" + ApiOperation.OPERATION_ID_1);
> {code}
> With best regards
> Vladimir
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-16290) camel-main-yaml - Yaml configuration loader
[ https://issues.apache.org/jira/browse/CAMEL-16290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-16290: Fix Version/s: 4.x (was: 3.x) > camel-main-yaml - Yaml configuration loader > --- > > Key: CAMEL-16290 > URL: https://issues.apache.org/jira/browse/CAMEL-16290 > Project: Camel > Issue Type: New Feature > Components: camel-main >Reporter: Claus Ibsen >Priority: Major > Fix For: 4.x > > > When using camel-main as standalone then we only have support for loading > .properties file for configuration. > Some users are on the yaml wagon, so we could consider adding a new > camel-main-yaml module that adds support for loading configuration from yaml > and comes out of the box with the yaml dsl too. > We can then make some kind of Main class for yaml that can startup Camel and > load application.yaml as configuration and load routes .yaml files as routes. > Then you can run Camel standalone in this yaml world. > And then this can be a way for also running Kamelets standalone by having > camel-kamelet included and being able to load kamelets yaml spec files. > Yes they are intended for k8s but it may be okay to try to develop and play > with kamelets without an entire k8s platform. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-16399) Add DynamoDB and DynamoDB Streams to camel-test-infra-aws-v2 module
[ https://issues.apache.org/jira/browse/CAMEL-16399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-16399: Fix Version/s: 4.x (was: 3.x) > Add DynamoDB and DynamoDB Streams to camel-test-infra-aws-v2 module > --- > > Key: CAMEL-16399 > URL: https://issues.apache.org/jira/browse/CAMEL-16399 > Project: Camel > Issue Type: Task > Components: tests >Reporter: Andrea Cosentino >Assignee: Andrea Cosentino >Priority: Minor > Fix For: 4.x > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-16431) Support for SSE and JSON Streaming
[ https://issues.apache.org/jira/browse/CAMEL-16431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-16431: Fix Version/s: 4.x (was: 3.x) > Support for SSE and JSON Streaming > -- > > Key: CAMEL-16431 > URL: https://issues.apache.org/jira/browse/CAMEL-16431 > Project: Camel > Issue Type: New Feature >Reporter: Luca Burgazzoli >Priority: Minor > Fix For: 4.x > > > We should evaluate adding support for [JSON > Streaming|https://en.wikipedia.org/wiki/JSON_streaming] and [Server Side > Events|https://en.wikipedia.org/wiki/Server-sent_events] i.e. we could create > the json-streaming and sse façade that delegate to real components (vertx, > platform-http, etc) -- 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: Fix Version/s: 4.x (was: Future) > 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: 4.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] [Updated] (CAMEL-17855) camel-test-infra: enable singleton instances for supported services/tests
[ https://issues.apache.org/jira/browse/CAMEL-17855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Otavio Rodolfo Piske updated CAMEL-17855: - Estimated Complexity: Moderate (was: Unknown) > camel-test-infra: enable singleton instances for supported services/tests > - > > Key: CAMEL-17855 > URL: https://issues.apache.org/jira/browse/CAMEL-17855 > Project: Camel > Issue Type: Test > Components: tests >Reporter: Otavio Rodolfo Piske >Priority: Major > Labels: help-wanted > Fix For: 4.x > > > Implement the same changes on [https://github.com/apache/camel/pull/7254] to > the other test infra services. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-16479) Camel-AWS-Kinesis: The consumer should be able to consume from multiple shards at the same time
[ https://issues.apache.org/jira/browse/CAMEL-16479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-16479: Fix Version/s: 4.x (was: 3.x) > Camel-AWS-Kinesis: The consumer should be able to consume from multiple > shards at the same time > --- > > Key: CAMEL-16479 > URL: https://issues.apache.org/jira/browse/CAMEL-16479 > Project: Camel > Issue Type: New Feature > Components: camel-aws >Reporter: Andrea Cosentino >Assignee: Andrea Cosentino >Priority: Major > Fix For: 4.x > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-16710) Quickfix component: InOut exchanges for producers are limited to exactly 1 FIX message type
[
https://issues.apache.org/jira/browse/CAMEL-16710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-16710:
Fix Version/s: Future
(was: 3.x)
> Quickfix component: InOut exchanges for producers are limited to exactly 1
> FIX message type
> ---
>
> Key: CAMEL-16710
> URL: https://issues.apache.org/jira/browse/CAMEL-16710
> Project: Camel
> Issue Type: Improvement
> Components: camel-quickfix
>Affects Versions: 3.7.0
>Reporter: Mathias Aebersold
>Priority: Minor
> Fix For: Future
>
>
> Hi there,
> we are implementing a Quickfix request-reply message exchange where the reply
> message can be one of 2 different message types, which is not supported by
> the current implementation. However, this is a common situation during FIX
> business processes. E.g. sending a QuoteRequest message will yield in a
> response of either a Quote or QuoteRequestReject message.
>
> The current implementation of the correlation criteria with a
> {{MessagePredicate}} object requires exactly 1 {{MsgType}} in its constructor:
> [https://camel.apache.org/components/latest/quickfix-component.html#_implementing_inout_exchanges_for_producers]
> {code:java}
> exchange.setProperty(QuickfixjProducer.CORRELATION_CRITERIA_KEY,
> new MessagePredicate(new SessionID(sessionID), MsgType.EXECUTION_REPORT)
> .withField(ExecTransType.FIELD,
> Integer.toString(ExecTransType.STATUS))
> .withField(OrderID.FIELD, request.getString(OrderID.FIELD)));
> {code}
>
>
> I see 2 potential approaches to improve the current implementation:
> h4. 1) Correlation criteria without a {{MsgType}}.
> This could be very quickly implemented using a new {{MessagePredicate
> }}constructor:
> Existing constructor:
> {code:java|title=org.apache.camel.component.quickfixj.MessagePredicate#MessagePredicate}
> public MessagePredicate(SessionID requestingSessionID, String msgType) {
> addHeaderFieldIfPresent(SenderCompID.FIELD,
> requestingSessionID.getSenderCompID());
> addHeaderFieldIfPresent(TargetCompID.FIELD,
> requestingSessionID.getTargetCompID());
> withMessageType(msgType);
> }
> {code}
> Proposed new constructor without the parameter {{String msgType}}:
> {code:java|title=org.apache.camel.component.quickfixj.MessagePredicate#MessagePredicate}
> public MessagePredicate(SessionID requestingSessionID) {
> addHeaderFieldIfPresent(SenderCompID.FIELD,
> requestingSessionID.getSenderCompID());
> addHeaderFieldIfPresent(TargetCompID.FIELD,
> requestingSessionID.getTargetCompID());
> }
> {code}
> h4. 2) Multiple {{MessagePredicate}} for different {{MsgType}}
> This approach would replace the existing correlation criteria consisting of a
> single {{MessagePredicate}} object with a list of {{MessagePredicate}}
> objects. An incoming message would be successfully correlated if any of the
> {{MessagePredicate}} objects would evaluate to {{true}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-16624) camel-salesforce - Replace Map Options with Multivalue
[ https://issues.apache.org/jira/browse/CAMEL-16624?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-16624: Fix Version/s: 4.x (was: 3.x) > camel-salesforce - Replace Map Options with Multivalue > -- > > Key: CAMEL-16624 > URL: https://issues.apache.org/jira/browse/CAMEL-16624 > Project: Camel > Issue Type: Improvement > Components: camel-salesforce >Affects Versions: 3.9.0 >Reporter: Hemang Ajmera >Priority: Minor > Fix For: 4.x > > > We should replace Map with Multi Value, so that they can be initialized in > URI sting. > > Please refer to > [https://camel.zulipchat.com/#narrow/stream/257298-camel/topic/set.20Map.20option/near/239077029] > for details > > The Map options in Salesforce Component are > # apexQueryParams > # initialReplayIdMap > > If there is quick way to find all the options in other component which is > Map, then this Jira can be extended to convert them all. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-17855) camel-test-infra: enable singleton instances for supported services/tests
[ https://issues.apache.org/jira/browse/CAMEL-17855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Otavio Rodolfo Piske updated CAMEL-17855: - Labels: help-wanted (was: ) > camel-test-infra: enable singleton instances for supported services/tests > - > > Key: CAMEL-17855 > URL: https://issues.apache.org/jira/browse/CAMEL-17855 > Project: Camel > Issue Type: Test > Components: tests >Reporter: Otavio Rodolfo Piske >Priority: Major > Labels: help-wanted > Fix For: 4.x > > > Implement the same changes on [https://github.com/apache/camel/pull/7254] to > the other test infra services. -- 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: Fix Version/s: Future (was: 3.x) > 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: Future > > > [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-17855) camel-test-infra: enable singleton instances for supported services/tests
[ https://issues.apache.org/jira/browse/CAMEL-17855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17752347#comment-17752347 ] Otavio Rodolfo Piske commented on CAMEL-17855: -- Yeah, this is an older ticket. I think what's missing is a review of the services that we can migrate and then include them here. Let me adjust this ticket a bit. > camel-test-infra: enable singleton instances for supported services/tests > - > > Key: CAMEL-17855 > URL: https://issues.apache.org/jira/browse/CAMEL-17855 > Project: Camel > Issue Type: Test > Components: tests >Reporter: Otavio Rodolfo Piske >Priority: Major > Fix For: 3.x > > > Implement the same changes on [https://github.com/apache/camel/pull/7254] to > the other test infra services. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-17855) camel-test-infra: enable singleton instances for supported services/tests
[ https://issues.apache.org/jira/browse/CAMEL-17855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Otavio Rodolfo Piske updated CAMEL-17855: - Fix Version/s: 4.x (was: 3.x) > camel-test-infra: enable singleton instances for supported services/tests > - > > Key: CAMEL-17855 > URL: https://issues.apache.org/jira/browse/CAMEL-17855 > Project: Camel > Issue Type: Test > Components: tests >Reporter: Otavio Rodolfo Piske >Priority: Major > Fix For: 4.x > > > Implement the same changes on [https://github.com/apache/camel/pull/7254] to > the other test infra services. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-16691) Support Google cloud dataproc kafka sink for kamelet
[ https://issues.apache.org/jira/browse/CAMEL-16691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-16691: Fix Version/s: Future (was: 3.x) > Support Google cloud dataproc kafka sink for kamelet > > > Key: CAMEL-16691 > URL: https://issues.apache.org/jira/browse/CAMEL-16691 > Project: Camel > Issue Type: New Feature >Reporter: Godfrey >Priority: Minor > Fix For: Future > > > Kafka *dataproc* sink is very useful to subscribe from Kafka topic into > Google cloud Dataproc (Apache spark). > *Dataproc* is a fast[, easy-to-use, > ful|https://cloud.google.com/dataproc/docs]ly managed cloud service for > running Apache Spark and Apache Hadoop clusters in a simpler, more > cost-efficient way. > Any ideas of how to create it related Kamelet? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-16791) camel-core - Aggregate EIP defaults to a worker queue size of 1000
[ https://issues.apache.org/jira/browse/CAMEL-16791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-16791: Fix Version/s: 4.x (was: 3.x) > camel-core - Aggregate EIP defaults to a worker queue size of 1000 > -- > > Key: CAMEL-16791 > URL: https://issues.apache.org/jira/browse/CAMEL-16791 > Project: Camel > Issue Type: Improvement > Components: came-core >Affects Versions: 3.11.0 >Reporter: Jeremy Ross >Assignee: Claus Ibsen >Priority: Major > Fix For: 4.x > > > Perhaps should default to 1, or make it easily globally configured. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-16809) Camel AWS2 S3: Add headers for recreating the access control list feature from SDK v1
[ https://issues.apache.org/jira/browse/CAMEL-16809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-16809: Fix Version/s: 4.x (was: 3.x) > Camel AWS2 S3: Add headers for recreating the access control list feature > from SDK v1 > - > > Key: CAMEL-16809 > URL: https://issues.apache.org/jira/browse/CAMEL-16809 > Project: Camel > Issue Type: Improvement > Components: camel-aws2 >Reporter: Andrea Cosentino >Assignee: Andrea Cosentino >Priority: Major > Fix For: 4.x > > > https://github.com/aws/aws-sdk-java-v2/issues/1703 > We could try to apply ACL in the way describe in this issue with a couple of > headers. We can do this on multipart and put object operations for beginnig. > This is related to CAMEL-16806 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-16789) camel-microprofile-faulttolerance: timeoutScheduledExecutorServiceRef and bulkHead* to be deprecated ?
[ https://issues.apache.org/jira/browse/CAMEL-16789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-16789: Fix Version/s: Future (was: 3.x) > camel-microprofile-faulttolerance: timeoutScheduledExecutorServiceRef and > bulkHead* to be deprecated ? > -- > > Key: CAMEL-16789 > URL: https://issues.apache.org/jira/browse/CAMEL-16789 > Project: Camel > Issue Type: Task >Reporter: Alex Dettinger >Priority: Minor > Fix For: Future > > > It looks like faulttolerance *timeoutScheduledExecutorServiceRef* and > *bulkHead** have no effect. > [FaultToleranceConfiguration.getTimeoutScheduledExecutorServiceRef()|https://github.com/apache/camel/blob/main/components/camel-microprofile/camel-microprofile-fault-tolerance/src/main/java/org/apache/camel/component/microprofile/faulttolerance/FaultToleranceConfiguration.java#L89..L91] > is never called from camel code, so the configured value is never reified > into an actual processor as far as I get it. > Concerning bulkHead*, the [FaultToleranceReifier does not > propagate|https://github.com/apache/camel/blob/main/components/camel-microprofile/camel-microprofile-fault-tolerance/src/main/java/org/apache/camel/component/microprofile/faulttolerance/FaultToleranceReifier.java#L103..L108] > the bulkHeadEnabled boolean by calling something like > *target.setBulkheadEnabled(true);* > As such, the FaultToleranceProcessor never actually executes the > [doStart()|https://github.com/apache/camel/blob/main/components/camel-microprofile/camel-microprofile-fault-tolerance/src/main/java/org/apache/camel/component/microprofile/faulttolerance/FaultToleranceProcessor.java#L348..L352] > and > [process()|https://github.com/apache/camel/blob/main/components/camel-microprofile/camel-microprofile-fault-tolerance/src/main/java/org/apache/camel/component/microprofile/faulttolerance/FaultToleranceProcessor.java#L239..L243] > code related to bulkhead. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-16826) Camel-Azure-Storage-Blob: Add deleteAfterRead option for consumer side
[ https://issues.apache.org/jira/browse/CAMEL-16826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-16826: Fix Version/s: 4.x (was: 3.x) > Camel-Azure-Storage-Blob: Add deleteAfterRead option for consumer side > -- > > Key: CAMEL-16826 > URL: https://issues.apache.org/jira/browse/CAMEL-16826 > Project: Camel > Issue Type: Improvement > Components: camel-azure >Reporter: Andrea Cosentino >Assignee: Andrea Cosentino >Priority: Minor > Fix For: 4.x > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-16829) camel-core - Stuck processing with nested parallel splits and custom thread pool
[
https://issues.apache.org/jira/browse/CAMEL-16829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-16829:
Fix Version/s: 4.x
(was: 3.x)
> camel-core - Stuck processing with nested parallel splits and custom thread
> pool
>
>
> Key: CAMEL-16829
> URL: https://issues.apache.org/jira/browse/CAMEL-16829
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 3.11.0
>Reporter: Samuel Padou
>Assignee: Claus Ibsen
>Priority: Minor
> Fix For: 4.x
>
>
> The cause of this issue is difficult to pinpoint, but running the following
> code, the route will be stuck indefinitely in processing:
> {code:java}
> @Component
> public static class Route extends RouteBuilder {
> @Override
> public void configure() throws Exception {
> final var executorService = new ThreadPoolBuilder(getContext())
> .poolSize(1)
> .maxPoolSize(1)
> .maxQueueSize(0)
> .build("inner");
> from("direct:main")
> .split(body()).parallelProcessing()
> .to("direct:inner?synchronous=true");
> from("direct:inner")
> .split(body()).executorService(executorService)
> .log("${body}");
> }
> }
> @Component
> public static class Runner implements CommandLineRunner {
> @Autowired
> private CamelContext camelContext;
> @Autowired
> private ProducerTemplate producerTemplate;
> @Override
> public void run(String... args) {
> final var exchange = new DefaultExchange(camelContext);
> exchange.getIn().setBody(List.of(List.of("0-0", "0-1"),
> List.of("1-0", "1-1")));
> producerTemplate.send("direct:main", exchange);
> }
> }
> {code}
> There are two important parts to reproduce the issue:
> * The forward to direct:inner with synchronous=true. This will cause an await
> here and it is the point where the route processing is stuck.
> * The inner executor, with a small pool and no queue, which will trigger the
> default CallerRuns rejection policy and run the split in the original thread
> instead of as new one.
> The cause of the stuck await seems to be linked to the way the
> AsyncProcessorAwaitManager and DefaultReactiveExecutor.executeFromQueue()
> interacts. Here the await callback to decrement the latch have been pushed in
> a back queue of the reactive worker (probably by a scheduleMain in the
> middle), but the executeFromQueue does not process the worker back queues so
> the callback is not executed and we are stuck on the await.
> I'm not sure what the solution is here, maybe the executeFromQueue should
> process back queues, or the CallerRuns rejection policy is just not supported
> in the first place but it should probably not be the default then.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-16825) can not use endChoice() in nest choice DSL
[
https://issues.apache.org/jira/browse/CAMEL-16825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-16825:
Fix Version/s: Future
(was: 3.x)
> can not use endChoice() in nest choice DSL
> --
>
> Key: CAMEL-16825
> URL: https://issues.apache.org/jira/browse/CAMEL-16825
> Project: Camel
> Issue Type: Improvement
> Components: camel-core, eip
>Affects Versions: 3.6.0, 3.11.0
>Reporter: tang honggang
>Priority: Minor
> Fix For: Future
>
>
> I want to use nest choice DSL to finish some job, but it doesn't work well in
> my test case. When I use endChoice() in the inner choice clause, it return
> back to the outer choice definition actually.
> And this is the test case:
> ProcessorDefinition end = from("timer:foo?period=5000&synchronous=true")
> .transform(simple("${random(1000)}"))
> .choice()
> .when(simple("${body} > 500"))
> .log("High number ${body}")
> .choice()
> .when(simple("${body} > 750"))
> .log("High number >750 ${body}")
> .endChoice()
> .otherwise()
> .log("High number <750 ${body}")
> .endChoice()
> .endChoice()
> .otherwise()
> .log("Low number ${body}")
> .endChoice();
>
> Though in this case, I can fix the problem by not use endChoice(), I see the
> code of endChoice(). I found that change the sequence of the two judgement
> below can fix my problem, but I am not sure the influence. So I hope you can
> give me an answer, thx!
> // are we nested choice?
> ProcessorDefinition def = this;
> if (def.getParent() instanceof WhenDefinition) {
> return (ChoiceDefinition) def.getParent().getParent();
> }
> // are we already a choice?
> if (def instanceof ChoiceDefinition) {
> return (ChoiceDefinition) def;
> }
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CAMEL-17177) camel-salesforce: migrate to the repeatable tasks
[ https://issues.apache.org/jira/browse/CAMEL-17177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17752346#comment-17752346 ] Otavio Rodolfo Piske commented on CAMEL-17177: -- It would be good to perform this migration, but I have no knowledge at all about Salesforce. I'm going to mark this one as help wanted. > camel-salesforce: migrate to the repeatable tasks > - > > Key: CAMEL-17177 > URL: https://issues.apache.org/jira/browse/CAMEL-17177 > Project: Camel > Issue Type: Task > Components: camel-salesforce >Affects Versions: 3.13.0 >Reporter: Otavio Rodolfo Piske >Priority: Minor > Labels: help-wanted > Fix For: Future > > > These methods may be candidates for moving to the repeatable tasks > implemented as part of CAMEL-17121: > * > org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper#performClientRestart > * > org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper#subscribe > I don't know much about Salesforce and it may require some more effort to > test. Therefore, logging and saving for later. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (CAMEL-17177) camel-salesforce: migrate to the repeatable tasks
[ https://issues.apache.org/jira/browse/CAMEL-17177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17752346#comment-17752346 ] Otavio Rodolfo Piske edited comment on CAMEL-17177 at 8/9/23 9:19 AM: -- It would be good to perform this migration, but I have no knowledge at all about Salesforce. was (Author: orpiske): It would be good to perform this migration, but I have no knowledge at all about Salesforce. I'm going to mark this one as help wanted. > camel-salesforce: migrate to the repeatable tasks > - > > Key: CAMEL-17177 > URL: https://issues.apache.org/jira/browse/CAMEL-17177 > Project: Camel > Issue Type: Task > Components: camel-salesforce >Affects Versions: 3.13.0 >Reporter: Otavio Rodolfo Piske >Priority: Minor > Labels: help-wanted > Fix For: Future > > > These methods may be candidates for moving to the repeatable tasks > implemented as part of CAMEL-17121: > * > org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper#performClientRestart > * > org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper#subscribe > I don't know much about Salesforce and it may require some more effort to > test. Therefore, logging and saving for later. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-16751) camel-core - API and SPI for Transactional Batch Consumer
[ https://issues.apache.org/jira/browse/CAMEL-16751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-16751: Fix Version/s: 4.x (was: 3.x) > camel-core - API and SPI for Transactional Batch Consumer > - > > Key: CAMEL-16751 > URL: https://issues.apache.org/jira/browse/CAMEL-16751 > Project: Camel > Issue Type: New Feature > Components: camel-core >Reporter: Claus Ibsen >Priority: Major > Fix For: 4.x > > > Some messaging components like JMS, RabbitMQ, Kafka etc can benefit from a > transactional batch API so we can group together X messages into a single > outgoing message from the consumer. > Something like the old SJMS Batch but more general and reusable for more > components. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-16861) Polish and cleanup documentation
[ https://issues.apache.org/jira/browse/CAMEL-16861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-16861: Fix Version/s: Future (was: 3.x) > Polish and cleanup documentation > > > Key: CAMEL-16861 > URL: https://issues.apache.org/jira/browse/CAMEL-16861 > Project: Camel > Issue Type: Task > Components: documentation >Reporter: Claus Ibsen >Assignee: Claus Ibsen >Priority: Major > Fix For: Future > > > The documentation needs some polishing and cleanup, and to remove obsolete > pages etc. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-16871) Support camel-aws2-s3 multipart with remote files
[
https://issues.apache.org/jira/browse/CAMEL-16871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-16871:
Fix Version/s: 4.x
(was: 3.x)
> Support camel-aws2-s3 multipart with remote files
> -
>
> Key: CAMEL-16871
> URL: https://issues.apache.org/jira/browse/CAMEL-16871
> Project: Camel
> Issue Type: Improvement
> Components: camel-aws2
>Reporter: Brendan
>Priority: Minor
> Fix For: 4.x
>
>
> Camel aws2-s3 mutlipart upload only supports Files.
>
> There are at least two approaches to solving this:
> The hard, general case and a simple specific case.
>
> 1) The harder but general case: use something like Spring's aws
> SimpleStorageInputStream:
> [https://github.com/spring-cloud/spring-cloud-aws/blob/main/spring-cloud-aws-core/src/main/java/org/springframework/cloud/aws/core/io/s3/SimpleStorageResource.java|http://example.com/]
> and translate any exchange body to an Inputstream for mulitpart uploads.
>
> 2) The simpler but specific case: for remote files in particular, camel often
> makes use of a localwork directory to download files. In fact,
> {code:java}
> e.getIn().getBody(File.class)
> {code}
> will resolve the file in the local work directory when polling from an FTP
> site with a local work directory specified.
>
> The aws2-s3 producer (AWS2S3Producer.class) on lines 134 to 145 would need to
> be modified in both cases.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-16866) camel-opentelemetry - Add metrics support
[ https://issues.apache.org/jira/browse/CAMEL-16866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-16866: Fix Version/s: 4.x (was: 3.x) > camel-opentelemetry - Add metrics support > - > > Key: CAMEL-16866 > URL: https://issues.apache.org/jira/browse/CAMEL-16866 > Project: Camel > Issue Type: New Feature > Components: camel-opentelemetry >Reporter: Claus Ibsen >Priority: Major > Fix For: 4.x > > > Currently we only have tracing support, but opentelemtry can also be used for > gather metrics. > Maybe look at how camel-micrometer is doing this > https://github.com/apache/camel/tree/main/components/camel-micrometer -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-16956) Camel AWS SQS: Really supports concurrent consumers
[ https://issues.apache.org/jira/browse/CAMEL-16956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-16956: Fix Version/s: 4.x (was: 3.x) > Camel AWS SQS: Really supports concurrent consumers > --- > > Key: CAMEL-16956 > URL: https://issues.apache.org/jira/browse/CAMEL-16956 > Project: Camel > Issue Type: Improvement > Components: camel-aws >Reporter: Andrea Cosentino >Assignee: Andrea Cosentino >Priority: Major > Fix For: 4.x > > > At the moment the concurrent consumers value is set on the consumer > scheduler. We need to do something like we are doing in camel-nats, where we > define a poolSize for the executor Services and spin up concurrent consumers > based on this value and an executor service. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CAMEL-16888) [camel-karaf] xml-specs-api features should be updated to use woodstox.core and stax2-api
[
https://issues.apache.org/jira/browse/CAMEL-16888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-16888.
-
Resolution: Fixed
We have updated karaf stuff
> [camel-karaf] xml-specs-api features should be updated to use woodstox.core
> and stax2-api
> -
>
> Key: CAMEL-16888
> URL: https://issues.apache.org/jira/browse/CAMEL-16888
> Project: Camel
> Issue Type: Improvement
> Components: karaf
>Reporter: Jean-Baptiste Onofré
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: 3.x
>
>
> {{xml-specs-api}} should be updated with:
> # use dependency=true on stax2-api and update to stax2-api 4.2 (aligned with
> other camel features)
> # use woodstox-core instead of woodstox-core-asl and update to woodstox 6.2.4
> # update jaxb-runtime bundle to 2.3.2_1 to match CXF one
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-17025) camel-aws-s3 - Allow moveAfterRead in same bucket for AWS S3 consumer
[ https://issues.apache.org/jira/browse/CAMEL-17025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-17025: Fix Version/s: 4.x (was: 3.x) > camel-aws-s3 - Allow moveAfterRead in same bucket for AWS S3 consumer > - > > Key: CAMEL-17025 > URL: https://issues.apache.org/jira/browse/CAMEL-17025 > Project: Camel > Issue Type: Improvement > Components: camel-aws, camel-aws2 >Reporter: Fabio Zani >Assignee: Andrea Cosentino >Priority: Minor > Fix For: 4.x > > > Using the AWS2 S3 component it would be nice to have a way to move a file > inside a different subfolder in the same bucket after reading it. > h1. AS IS > With the current implementation, the _moveAfterRead_ option requires to > specify the destination bucket and eventually a prefix and/or suffix. > As it is not intended for moving into a different folder in the same bucket, > trying to specify the original bucket as destination and the path to the > subfolder as a prefix has an _ugly_ result, as shown in the following example. > Original bucket: myBucket > File path: /path/to/foloder/run/test.txt > _moveAfterRead=true_ > _destinationBucket=myBucket_ > _destinationBucketPrefix=/path/to/folder/done_ > Result: file is moved, but file key is > _/path/to/folder/done/path/to/folder/test.txt_ > h1. TO BE > Allow moving the file under a different folder in the same bucket. > An option would be to recognize if the destination bucket is the same as the > original bucket, requiring the destinationBuketPrefix to be set, moving the > file (with the filename extracted from the _CamelAwsS3Key_) under the > specified prefix. > Another option would be to introduce a new option designed specifically to > move the file within the same bucket. The moveAfterRead option would then > require either the _destinationBucket_ option or the > _destinationSubfolderPrefix_ to be set. > In case the second solution is chosen, the _destinationBucketSuffix_ option > could be renamed in _destinationSuffix_ to be used with both moving within > the bucket or to another bucket or a new option > (_destinationSubfolderSuffix_) should be introduced. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-17027) camel-aws-a3 - Streaming mode upload avoid stream into memory
[ https://issues.apache.org/jira/browse/CAMEL-17027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-17027: Fix Version/s: 4.x (was: 3.x) > camel-aws-a3 - Streaming mode upload avoid stream into memory > - > > Key: CAMEL-17027 > URL: https://issues.apache.org/jira/browse/CAMEL-17027 > Project: Camel > Issue Type: Improvement > Components: camel-aws >Reporter: Claus Ibsen >Priority: Major > Fix For: 4.x > > > We should look at the streaming mode as it loads the stream into memory to > copy to the s3 client. > We can maybe do this a bit smarter, to write in chunks. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-17235) Camel-Infinispan: Support Ickle queries
[ https://issues.apache.org/jira/browse/CAMEL-17235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-17235: Fix Version/s: Future (was: 3.x) > Camel-Infinispan: Support Ickle queries > --- > > Key: CAMEL-17235 > URL: https://issues.apache.org/jira/browse/CAMEL-17235 > Project: Camel > Issue Type: New Feature > Components: camel-infinispan >Reporter: Andrea Cosentino >Assignee: Andrea Cosentino >Priority: Minor > Fix For: Future > > > https://infinispan.org/docs/stable/titles/query/query.html#ickle-queries_ickle-query-language -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-17193) Move spring boot component documentation to its own
[ https://issues.apache.org/jira/browse/CAMEL-17193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-17193: Fix Version/s: Future (was: 3.x) > Move spring boot component documentation to its own > --- > > Key: CAMEL-17193 > URL: https://issues.apache.org/jira/browse/CAMEL-17193 > Project: Camel > Issue Type: Task > Components: build system, documentation >Reporter: Claus Ibsen >Priority: Major > Fix For: Future > > > Spring Boot has special section added to the camel core projects component > docs. > The other sub projects does not. > We should move this to its own camel spring boot docs, like we do for > camel-quarkus > https://camel.apache.org/camel-quarkus/next/reference/extensions/asterisk.html > Then we can have generated something similar as above that has this spring > boot auto configuration table. And any custom spring boot doc for this > particular component. > This makes the core documentation vanilla. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-17177) camel-salesforce: migrate to the repeatable tasks
[ https://issues.apache.org/jira/browse/CAMEL-17177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-17177: Fix Version/s: Future (was: 3.x) > camel-salesforce: migrate to the repeatable tasks > - > > Key: CAMEL-17177 > URL: https://issues.apache.org/jira/browse/CAMEL-17177 > Project: Camel > Issue Type: Task > Components: camel-salesforce >Affects Versions: 3.13.0 >Reporter: Otavio Rodolfo Piske >Priority: Minor > Labels: help-wanted > Fix For: Future > > > These methods may be candidates for moving to the repeatable tasks > implemented as part of CAMEL-17121: > * > org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper#performClientRestart > * > org.apache.camel.component.salesforce.internal.streaming.SubscriptionHelper#subscribe > I don't know much about Salesforce and it may require some more effort to > test. Therefore, logging and saving for later. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-17254) camel-jfr - Expose coarse grained metrics for context/route
[ https://issues.apache.org/jira/browse/CAMEL-17254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-17254: Fix Version/s: Future (was: 3.x) > camel-jfr - Expose coarse grained metrics for context/route > --- > > Key: CAMEL-17254 > URL: https://issues.apache.org/jira/browse/CAMEL-17254 > Project: Camel > Issue Type: New Feature > Components: camel-jfr >Reporter: Claus Ibsen >Priority: Major > Fix For: Future > > > It can be beneficial to allow JFR to stream metrics once per second with > aggregated metrics for context / per route. > When analysing the JVM performance then you would like to know the "load" > from Camel in terms of number of messages inflight at a given time etc. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-17173) camel-jetty and http server components - Mute exception should default be enabled
[ https://issues.apache.org/jira/browse/CAMEL-17173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-17173: Fix Version/s: Future (was: 3.x) > camel-jetty and http server components - Mute exception should default be > enabled > - > > Key: CAMEL-17173 > URL: https://issues.apache.org/jira/browse/CAMEL-17173 > Project: Camel > Issue Type: Improvement >Reporter: Claus Ibsen >Priority: Major > Fix For: Future > > > This avoids returning exceptions with stacktraces etc over http. > However this is good for development but not for production. > And we should have a new option to log exceptions on the server side so when > there are unhandled exceptions then they are logged on server, and a http 500 > with empty body is returned (mute exception). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-17040) rest-dsl - Add option to return http 204 when no data in response
[ https://issues.apache.org/jira/browse/CAMEL-17040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-17040: Fix Version/s: 4.x (was: 3.x) > rest-dsl - Add option to return http 204 when no data in response > - > > Key: CAMEL-17040 > URL: https://issues.apache.org/jira/browse/CAMEL-17040 > Project: Camel > Issue Type: Improvement > Components: camel-core, rest >Reporter: Claus Ibsen >Priority: Major > Fix For: 4.x > > > For example if you have a json response as an empty list, then you can get a > 200 OK with [] as response. > Or with an XML then it may be an empty xml root object. > It may be desirable to have an option you can set to true to let Camel > auto-detect this and return no body and 204 instead. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-17111) Camel-AWS2-S3: Supporting Consumer idempotency in some way
[ https://issues.apache.org/jira/browse/CAMEL-17111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-17111: Fix Version/s: 4.x (was: 3.x) > Camel-AWS2-S3: Supporting Consumer idempotency in some way > -- > > Key: CAMEL-17111 > URL: https://issues.apache.org/jira/browse/CAMEL-17111 > Project: Camel > Issue Type: Improvement > Components: camel-aws2 >Reporter: Andrea Cosentino >Assignee: Andrea Cosentino >Priority: Major > Fix For: 4.x > > > Investigate if we could do something like internal idempotency in Aws2 s3 > consumer, instead of using deleteAfterRead as default approach. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-17270) camel-dsl - Java, groovy, kotlin, javascript - Align and support camel-k style
[ https://issues.apache.org/jira/browse/CAMEL-17270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-17270: Fix Version/s: 4.x (was: 3.x) > camel-dsl - Java, groovy, kotlin, javascript - Align and support camel-k style > -- > > Key: CAMEL-17270 > URL: https://issues.apache.org/jira/browse/CAMEL-17270 > Project: Camel > Issue Type: New Feature >Reporter: Claus Ibsen >Priority: Major > Fix For: 4.x > > > We can load route(s) from those DSLs. > In camel-k you can however have additional features, such as setting up > beans, components etc. > And it would also be good if we can parse if there are helper methods, than > just the route configure method. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-17315) Create an AWS Redshift Data Component
[ https://issues.apache.org/jira/browse/CAMEL-17315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-17315: Fix Version/s: 4.x (was: 3.x) > Create an AWS Redshift Data Component > - > > Key: CAMEL-17315 > URL: https://issues.apache.org/jira/browse/CAMEL-17315 > Project: Camel > Issue Type: New Feature > Components: camel-aws2 >Reporter: Andrea Cosentino >Assignee: Andrea Cosentino >Priority: Major > Fix For: 4.x > > > In this way we can create a specific component in camel for talking with a > Redshift cluster and execute queries against it. > This is a different client from the redshift one: the latter is the client to > create and manage Redshift clusters. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-17318) Add an AWS Timestream component
[ https://issues.apache.org/jira/browse/CAMEL-17318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-17318: Fix Version/s: 4.x (was: 3.x) > Add an AWS Timestream component > --- > > Key: CAMEL-17318 > URL: https://issues.apache.org/jira/browse/CAMEL-17318 > Project: Camel > Issue Type: New Feature > Components: camel-aws2 >Reporter: Andrea Cosentino >Assignee: Andrea Cosentino >Priority: Major > Fix For: 4.x > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-17305) HTTP server components - Add SPI to track http endpoints the currently expose
[ https://issues.apache.org/jira/browse/CAMEL-17305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-17305: Fix Version/s: 4.x (was: 3.x) > HTTP server components - Add SPI to track http endpoints the currently expose > - > > Key: CAMEL-17305 > URL: https://issues.apache.org/jira/browse/CAMEL-17305 > Project: Camel > Issue Type: New Feature >Reporter: Claus Ibsen >Priority: Major > Fix For: 4.x > > > Like we have in camel-platform-http to make it universal across http server > components so we can capture the endpoints that Camel exposes. This allows us > to report this to end users so they know what url they can call. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-17339) Avoid List as configuration parameter types in Endpoint configurations
[ https://issues.apache.org/jira/browse/CAMEL-17339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-17339: Fix Version/s: 4.x (was: 3.x) > Avoid List as configuration parameter types in Endpoint configurations > -- > > Key: CAMEL-17339 > URL: https://issues.apache.org/jira/browse/CAMEL-17339 > Project: Camel > Issue Type: Improvement >Reporter: Andrea Cosentino >Assignee: Andrea Cosentino >Priority: Major > Fix For: 4.x > > > Let's try to avoid this, it's better to have a comma separated string for > Kamelets purpose, but also because it is much more cleaner in terms of > reifiers. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-17339) Avoid List as configuration parameter types in Endpoint configurations
[ https://issues.apache.org/jira/browse/CAMEL-17339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-17339: Component/s: tooling > Avoid List as configuration parameter types in Endpoint configurations > -- > > Key: CAMEL-17339 > URL: https://issues.apache.org/jira/browse/CAMEL-17339 > Project: Camel > Issue Type: Improvement > Components: tooling >Reporter: Andrea Cosentino >Assignee: Andrea Cosentino >Priority: Major > Fix For: 4.x > > > Let's try to avoid this, it's better to have a comma separated string for > Kamelets purpose, but also because it is much more cleaner in terms of > reifiers. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-17368) camel-google-functions - Support GKE's workload identity
[ https://issues.apache.org/jira/browse/CAMEL-17368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-17368: Fix Version/s: 4.x (was: 3.x) > camel-google-functions - Support GKE's workload identity > > > Key: CAMEL-17368 > URL: https://issues.apache.org/jira/browse/CAMEL-17368 > Project: Camel > Issue Type: Improvement > Components: camel-google >Reporter: Andrea Cosentino >Assignee: Andrea Cosentino >Priority: Minor > Fix For: 4.x > > > Like CAMEL-16883 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-17348) camel-jira component newIssue does not work across multiple projects
[ https://issues.apache.org/jira/browse/CAMEL-17348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-17348: Fix Version/s: Future (was: 3.x) > camel-jira component newIssue does not work across multiple projects > > > Key: CAMEL-17348 > URL: https://issues.apache.org/jira/browse/CAMEL-17348 > Project: Camel > Issue Type: Improvement > Components: camel-jira >Affects Versions: 3.14.0 >Reporter: Zachary Gutterman >Priority: Minor > Fix For: Future > > Attachments: Screen Shot 2021-12-16 at 10.52.10 AM.png > > > The camel-Jira newIssue endpoint depends on Jira's sorting by id to find the > most recent issue. Jira sort by id, however, does not sort across all > projects and is not a reliable way to return a list of newest issues. (See > attached screenshot of sorted issues by id desc with endpoint > [/rest/api/latest/search?jql=ORDER+BY+id+desc|https://zachtestjira.atlassian.net/rest/api/latest/search?jql=ORDER+BY+id+desc].) > A solution could use the "created" field instead which reliably returns > issues by most recent. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-17369) Camel-google-storage - Support GKE's workload identity
[ https://issues.apache.org/jira/browse/CAMEL-17369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-17369: Fix Version/s: 4.x (was: 3.x) > Camel-google-storage - Support GKE's workload identity > -- > > Key: CAMEL-17369 > URL: https://issues.apache.org/jira/browse/CAMEL-17369 > Project: Camel > Issue Type: Improvement > Components: camel-google >Reporter: Andrea Cosentino >Assignee: Andrea Cosentino >Priority: Minor > Fix For: 4.x > > > Like CAMEL-16883 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (CAMEL-17423) Google Pubsub Authentication
[
https://issues.apache.org/jira/browse/CAMEL-17423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-17423:
Fix Version/s: 4.x
(was: 3.x)
> Google Pubsub Authentication
>
>
> Key: CAMEL-17423
> URL: https://issues.apache.org/jira/browse/CAMEL-17423
> Project: Camel
> Issue Type: Improvement
> Components: camel-google-pubsub
>Affects Versions: 3.14.0
>Reporter: Rob Arnhart
>Priority: Minor
> Fix For: 4.x
>
>
> I work for a cloud service provider that includes an integration application
> that uses Camel for the core operations of an integration. Because of factors
> such as industry regulation and customer InfoSec policies/requirements,
> placing access keys within an application, its filesystem, associated direct
> data stores, etc. is not permitted. This requires credentials to be provided
> by a lookup service that provides decrypted values to an application, exposed
> through variables. While our SaaS offering does provide an identity hub that
> integrates with customer IdPs, these integration applications will not use
> those as credential stores, directly.
> With that, the {{serviceAccountKey}} would need to be provided via a
> variable, environment variable, etc., where the JSON string would be passed
> into that field value.
> I've made a modification to allow for this by modifying the
> {{getCredentialsProvider}} method of the {{GooglePubsubCompenent.java}} file
> of the {{camel-google-pubsub}} component. This would respond to a prefix and
> then take the value from the passed parameter and use it for the credentials.
> {code:java|title=GooglePubsubComponent.java|borderStyle=solid}
> private CredentialsProvider getCredentialsProvider(GooglePubsubEndpoint
> endpoint) throws IOException {
> CredentialsProvider credentialsProvider;
> // The original method logic
> //if (endpoint.isAuthenticate()) {
> //credentialsProvider =
> FixedCredentialsProvider.create(ObjectHelper.isEmpty(endpoint.getServiceAccountKey())
> //? GoogleCredentials.getApplicationDefault() :
> ServiceAccountCredentials.fromStream(ResourceHelper
> //
> .resolveMandatoryResourceAsInputStream(getCamelContext(),
> endpoint.getServiceAccountKey(;
> //} else {
> //credentialsProvider = NoCredentialsProvider.create();
> //}
> // Modified for JSON input
> if (endpoint.isAuthenticate()) {
> if (ObjectHelper.isEmpty(endpoint.getServiceAccountKey())) {
> credentialsProvider =
> FixedCredentialsProvider.create(GoogleCredentials.getApplicationDefault());
> } else if (endpoint.getServiceAccountKey().startsWith("json:")) {
> // <- For the JSON string
> credentialsProvider =
> FixedCredentialsProvider.create(ServiceAccountCredentials.fromStream(
> new
> ByteArrayInputStream(Base64.getUrlDecoder().decode(endpoint.getServiceAccountKey().substring(5);
> } else {
> credentialsProvider =
> FixedCredentialsProvider.create(ServiceAccountCredentials.fromStream(
>
> ResourceHelper.resolveResourceAsInputStream(getCamelContext(),
> endpoint.getServiceAccountKey(;
> }
> } else {
> credentialsProvider = NoCredentialsProvider.create();
> }
> return credentialsProvider;
> }
> {code}
> This would then allows for the component to be defined with the
> {{serviceAccountKey}} as below. The JSON string would need to be encoded via
> Base64 to allow the internal encoded key to be properly passed through.
> {code:java|title=GcpPubsubRoute.java|borderStyle=solid}
> @Override
> public void configure() throws Exception {
> from("direct:gcpTest").id("gcpTest")
> .setHeader(GooglePubsubConstants.ATTRIBUTES,
> constant(Map.of("testKey1", "testValue1", "testKey2",
> "testValue2")))
> .setBody(simple("{\"someKey\": \"someValue\"}"))
>
> .toD("google-pubsub:{{PROJECT_NAME}}:{{TOPIC_NAME}}?serviceAccountKey=json:{{BASE64_CREDS}}")
> .log("Message ID: ${header." + GooglePubsubConstants.MESSAGE_ID +
> "}");
> }
> {code}
> I understand the concern around using an environment variable to pass
> credentials to a container. There is, however, a common pattern of cloud
> providers that expose external configuration to containers through
> environment variables.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CAMEL-17502) add documentation about event notifier
[ https://issues.apache.org/jira/browse/CAMEL-17502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-17502: Fix Version/s: Future (was: 3.x) > add documentation about event notifier > -- > > Key: CAMEL-17502 > URL: https://issues.apache.org/jira/browse/CAMEL-17502 > Project: Camel > Issue Type: Improvement > Components: documentation >Reporter: Claus Ibsen >Priority: Minor > Fix For: Future > > > How to use a custom event notifier to listen to camel events, such as context > stopping etc. -- This message was sent by Atlassian Jira (v8.20.10#820010)
