[jira] [Resolved] (CAMEL-12648) ExchangeSentEvent not fired if no EventNotifier is accepting ExchangeSendingEvent
[ https://issues.apache.org/jira/browse/CAMEL-12648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-12648. - Resolution: Not A Problem Assignee: Claus Ibsen Fix Version/s: 2.23.0 > ExchangeSentEvent not fired if no EventNotifier is accepting > ExchangeSendingEvent > - > > Key: CAMEL-12648 > URL: https://issues.apache.org/jira/browse/CAMEL-12648 > Project: Camel > Issue Type: Bug > Components: camel-core >Affects Versions: 2.20.0, 2.21.0, 2.22.0 >Reporter: Kevin Garner >Assignee: Claus Ibsen >Priority: Major > Fix For: 2.23.0 > > > Due to changes in CAMEL-11346, many processors (including SendProcessor) no > longer send ExchangeSentEvent when processing is done. The StopWatch object > is not created when EventHelper.notifyExchangeSending returns false. If no > EventNotifier is registered to receive that event, it will be false. But an > EventNotifier may still be registered to receive ExchangeSentEvent. The > StopWatch should be created when there is an EventNotifier registered for > ExchangeSentEvent even when ExchangeSendingEvent is not, unless those events > are always required to be paired together. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CAMEL-12648) ExchangeSentEvent not fired if no EventNotifier is accepting ExchangeSendingEvent
[ https://issues.apache.org/jira/browse/CAMEL-12648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16542619#comment-16542619 ] Claus Ibsen commented on CAMEL-12648: - Ah sorry, yes they are ment to be paired. See the javadoc of their classes. > ExchangeSentEvent not fired if no EventNotifier is accepting > ExchangeSendingEvent > - > > Key: CAMEL-12648 > URL: https://issues.apache.org/jira/browse/CAMEL-12648 > Project: Camel > Issue Type: Bug > Components: camel-core >Affects Versions: 2.20.0, 2.21.0, 2.22.0 >Reporter: Kevin Garner >Priority: Major > > Due to changes in CAMEL-11346, many processors (including SendProcessor) no > longer send ExchangeSentEvent when processing is done. The StopWatch object > is not created when EventHelper.notifyExchangeSending returns false. If no > EventNotifier is registered to receive that event, it will be false. But an > EventNotifier may still be registered to receive ExchangeSentEvent. The > StopWatch should be created when there is an EventNotifier registered for > ExchangeSentEvent even when ExchangeSendingEvent is not, unless those events > are always required to be paired together. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CAMEL-12643) camel-rabbitmq - Inadequate information for handling catch clauses
[
https://issues.apache.org/jira/browse/CAMEL-12643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-12643.
-
Resolution: Fixed
Assignee: Claus Ibsen
Fix Version/s: 2.23.0
Thanks for the PR
> camel-rabbitmq - Inadequate information for handling catch clauses
> --
>
> Key: CAMEL-12643
> URL: https://issues.apache.org/jira/browse/CAMEL-12643
> Project: Camel
> Issue Type: Improvement
> Components: camel-rabbitmq
>Reporter: Zhenhao Li
>Assignee: Claus Ibsen
>Priority: Minor
> Fix For: 2.23.0
>
>
> There are some situations that different exception types are caught, but the
> handling of those exceptions cannot show the differences between those types.
> Here are the code snippets which have this problem:
> {code}
> org.apache.camel.component.rabbitmq.*RabbitConsumer*.handleShutdownSignal,
> *Line 271*
> catch (IOException | TimeoutException e)
> { log.warn("Unable to obtain a RabbitMQ channel. Will try again"); ...
> }
> {code}
> It may cause confusions to the person who is reading the log, the person can
> not know what exception happened here and cannot distinguish if the exception
> type is IOException or TimeoutException. Simply adding a full stack trace is
> able to improve it.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CAMEL-12643) camel-rabbitmq - Inadequate information for handling catch clauses
[
https://issues.apache.org/jira/browse/CAMEL-12643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16542584#comment-16542584
]
ASF GitHub Bot commented on CAMEL-12643:
Github user davsclaus closed the pull request at:
https://github.com/apache/camel/pull/2422
> camel-rabbitmq - Inadequate information for handling catch clauses
> --
>
> Key: CAMEL-12643
> URL: https://issues.apache.org/jira/browse/CAMEL-12643
> Project: Camel
> Issue Type: Improvement
> Components: camel-rabbitmq
>Reporter: Zhenhao Li
>Priority: Minor
>
> There are some situations that different exception types are caught, but the
> handling of those exceptions cannot show the differences between those types.
> Here are the code snippets which have this problem:
> {code}
> org.apache.camel.component.rabbitmq.*RabbitConsumer*.handleShutdownSignal,
> *Line 271*
> catch (IOException | TimeoutException e)
> { log.warn("Unable to obtain a RabbitMQ channel. Will try again"); ...
> }
> {code}
> It may cause confusions to the person who is reading the log, the person can
> not know what exception happened here and cannot distinguish if the exception
> type is IOException or TimeoutException. Simply adding a full stack trace is
> able to improve it.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CAMEL-12643) camel-rabbitmq - Inadequate information for handling catch clauses
[
https://issues.apache.org/jira/browse/CAMEL-12643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16542583#comment-16542583
]
ASF GitHub Bot commented on CAMEL-12643:
davsclaus closed pull request #2422: CAMEL-12643: Inadequate information for
handling catch clauses
URL: https://github.com/apache/camel/pull/2422
This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:
As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):
diff --git
a/components/camel-rabbitmq/src/main/java/org/apache/camel/component/rabbitmq/RabbitConsumer.java
b/components/camel-rabbitmq/src/main/java/org/apache/camel/component/rabbitmq/RabbitConsumer.java
index b30a05171e7..e6a07296dcd 100644
---
a/components/camel-rabbitmq/src/main/java/org/apache/camel/component/rabbitmq/RabbitConsumer.java
+++
b/components/camel-rabbitmq/src/main/java/org/apache/camel/component/rabbitmq/RabbitConsumer.java
@@ -268,7 +268,7 @@ public void handleShutdownSignal(String consumerTag,
ShutdownSignalException sig
reconnect();
connected = true;
} catch (IOException | TimeoutException e) {
-log.warn("Unable to obtain a RabbitMQ channel. Will try
again");
+log.warn("Unable to obtain a RabbitMQ channel. Will try
again." + " Caused by: " + e.getMessage());
Integer networkRecoveryInterval =
consumer.getEndpoint().getNetworkRecoveryInterval();
final long connectionRetryInterval =
networkRecoveryInterval != null && networkRecoveryInterval > 0
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> camel-rabbitmq - Inadequate information for handling catch clauses
> --
>
> Key: CAMEL-12643
> URL: https://issues.apache.org/jira/browse/CAMEL-12643
> Project: Camel
> Issue Type: Improvement
> Components: camel-rabbitmq
>Reporter: Zhenhao Li
>Priority: Minor
>
> There are some situations that different exception types are caught, but the
> handling of those exceptions cannot show the differences between those types.
> Here are the code snippets which have this problem:
> {code}
> org.apache.camel.component.rabbitmq.*RabbitConsumer*.handleShutdownSignal,
> *Line 271*
> catch (IOException | TimeoutException e)
> { log.warn("Unable to obtain a RabbitMQ channel. Will try again"); ...
> }
> {code}
> It may cause confusions to the person who is reading the log, the person can
> not know what exception happened here and cannot distinguish if the exception
> type is IOException or TimeoutException. Simply adding a full stack trace is
> able to improve it.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CAMEL-12647) Problem in setting region for camel AWS-SQS endpoint
[
https://issues.apache.org/jira/browse/CAMEL-12647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16542557#comment-16542557
]
ASF GitHub Bot commented on CAMEL-12647:
saravanakumar1987 commented on issue #2424: CAMEL-12647 : Problem in setting
region for camel AWS-SQS endpoint
URL: https://github.com/apache/camel/pull/2424#issuecomment-404734327
aws-sns does not have this problem.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Problem in setting region for camel AWS-SQS endpoint
>
>
> Key: CAMEL-12647
> URL: https://issues.apache.org/jira/browse/CAMEL-12647
> Project: Camel
> Issue Type: Bug
> Components: camel-aws
>Affects Versions: 2.21.1
>Reporter: Saravanakumar Selvaraj
>Priority: Major
>
> It gives FailedToCreateRouteException while creating camel AWS-SQS endpoint
> with ARN.
> For example, below producer or consumer endpoint is not being created.
> {code:java}
> uri="aws-sqs://arn:aws:sqs:us-east-2:account:MyQueue?accessKey=xxx&secretKey=yyy®ion=US_EAST_2"{code}
> And it throws error as follows.
> {code:java}
> Caused by: java.lang.IllegalArgumentException: No enum constant
> com.amazonaws.regions.Regions.us-east-2
> at java.lang.Enum.valueOf(Enum.java:238)
> at com.amazonaws.regions.Regions.valueOf(Regions.java:26)
> at
> org.apache.camel.component.aws.sqs.SqsEndpoint.createClient(SqsEndpoint.java:310)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CAMEL-12647) Problem in setting region for camel AWS-SQS endpoint
[
https://issues.apache.org/jira/browse/CAMEL-12647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16542556#comment-16542556
]
ASF GitHub Bot commented on CAMEL-12647:
saravanakumar1987 commented on issue #2424: CAMEL-12647 : Problem in setting
region for camel AWS-SQS endpoint
URL: https://github.com/apache/camel/pull/2424#issuecomment-404734149
ARN is actually created like “arn:aws:sqs:us-east-2:account:MyQueue”. You
can try creating a SQS Queue in Aws and check the syntax of ARN. It’s not the
right place to get Region. Later the value is directly used in com.amazonaws
API directly and gives problem in enum. Check the error message I posted in
CAMEL-12647.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Problem in setting region for camel AWS-SQS endpoint
>
>
> Key: CAMEL-12647
> URL: https://issues.apache.org/jira/browse/CAMEL-12647
> Project: Camel
> Issue Type: Bug
> Components: camel-aws
>Affects Versions: 2.21.1
>Reporter: Saravanakumar Selvaraj
>Priority: Major
>
> It gives FailedToCreateRouteException while creating camel AWS-SQS endpoint
> with ARN.
> For example, below producer or consumer endpoint is not being created.
> {code:java}
> uri="aws-sqs://arn:aws:sqs:us-east-2:account:MyQueue?accessKey=xxx&secretKey=yyy®ion=US_EAST_2"{code}
> And it throws error as follows.
> {code:java}
> Caused by: java.lang.IllegalArgumentException: No enum constant
> com.amazonaws.regions.Regions.us-east-2
> at java.lang.Enum.valueOf(Enum.java:238)
> at com.amazonaws.regions.Regions.valueOf(Regions.java:26)
> at
> org.apache.camel.component.aws.sqs.SqsEndpoint.createClient(SqsEndpoint.java:310)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CAMEL-12648) ExchangeSentEvent not fired if no EventNotifier is accepting ExchangeSendingEvent
[ https://issues.apache.org/jira/browse/CAMEL-12648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16542542#comment-16542542 ] Claus Ibsen commented on CAMEL-12648: - Didnt we fix this recently, try with latest snapshot code. > ExchangeSentEvent not fired if no EventNotifier is accepting > ExchangeSendingEvent > - > > Key: CAMEL-12648 > URL: https://issues.apache.org/jira/browse/CAMEL-12648 > Project: Camel > Issue Type: Bug > Components: camel-core >Affects Versions: 2.20.0, 2.21.0, 2.22.0 >Reporter: Kevin Garner >Priority: Major > > Due to changes in CAMEL-11346, many processors (including SendProcessor) no > longer send ExchangeSentEvent when processing is done. The StopWatch object > is not created when EventHelper.notifyExchangeSending returns false. If no > EventNotifier is registered to receive that event, it will be false. But an > EventNotifier may still be registered to receive ExchangeSentEvent. The > StopWatch should be created when there is an EventNotifier registered for > ExchangeSentEvent even when ExchangeSendingEvent is not, unless those events > are always required to be paired together. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CAMEL-12647) Problem in setting region for camel AWS-SQS endpoint
[
https://issues.apache.org/jira/browse/CAMEL-12647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16542541#comment-16542541
]
ASF GitHub Bot commented on CAMEL-12647:
onderson commented on a change in pull request #2424: CAMEL-12647 : Problem in
setting region for camel AWS-SQS endpoint
URL: https://github.com/apache/camel/pull/2424#discussion_r202247330
##
File path:
components/camel-aws/src/test/java/org/apache/camel/component/aws/sqs/SqsComponentConfigurationTest.java
##
@@ -73,9 +73,9 @@ public void createEndpointWithMinimalArnConfiguration()
throws Exception {
((JndiRegistry) ((PropertyPlaceholderDelegateRegistry)
context.getRegistry()).getRegistry()).bind("amazonSQSClient", mock);
SqsComponent component = new SqsComponent(context);
-SqsEndpoint endpoint = (SqsEndpoint)
component.createEndpoint("aws-sqs://arn:aws:sqs:region:account:MyQueue?amazonSQSClient=#amazonSQSClient&accessKey=xxx&secretKey=yyy");
+SqsEndpoint endpoint = (SqsEndpoint)
component.createEndpoint("aws-sqs://arn:aws:sqs:region:account:MyQueue?amazonSQSClient=#amazonSQSClient&accessKey=xxx&secretKey=yyy®ion=US_EAST_2");
-assertEquals("region", endpoint.getConfiguration().getRegion());
Review comment:
Why not?
sqs://arn:aws:sqs:US_EAST_2:account:MyQueue?amazonSQSClient=#amazonSQSClient&accessKey=xxx&secretKey=yyy
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Problem in setting region for camel AWS-SQS endpoint
>
>
> Key: CAMEL-12647
> URL: https://issues.apache.org/jira/browse/CAMEL-12647
> Project: Camel
> Issue Type: Bug
> Components: camel-aws
>Affects Versions: 2.21.1
>Reporter: Saravanakumar Selvaraj
>Priority: Major
>
> It gives FailedToCreateRouteException while creating camel AWS-SQS endpoint
> with ARN.
> For example, below producer or consumer endpoint is not being created.
> {code:java}
> uri="aws-sqs://arn:aws:sqs:us-east-2:account:MyQueue?accessKey=xxx&secretKey=yyy®ion=US_EAST_2"{code}
> And it throws error as follows.
> {code:java}
> Caused by: java.lang.IllegalArgumentException: No enum constant
> com.amazonaws.regions.Regions.us-east-2
> at java.lang.Enum.valueOf(Enum.java:238)
> at com.amazonaws.regions.Regions.valueOf(Regions.java:26)
> at
> org.apache.camel.component.aws.sqs.SqsEndpoint.createClient(SqsEndpoint.java:310)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CAMEL-12647) Problem in setting region for camel AWS-SQS endpoint
[
https://issues.apache.org/jira/browse/CAMEL-12647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16542539#comment-16542539
]
ASF GitHub Bot commented on CAMEL-12647:
saravanakumar1987 commented on a change in pull request #2424: CAMEL-12647 :
Problem in setting region for camel AWS-SQS endpoint
URL: https://github.com/apache/camel/pull/2424#discussion_r202246177
##
File path:
components/camel-aws/src/test/java/org/apache/camel/component/aws/sqs/SqsComponentConfigurationTest.java
##
@@ -73,9 +73,9 @@ public void createEndpointWithMinimalArnConfiguration()
throws Exception {
((JndiRegistry) ((PropertyPlaceholderDelegateRegistry)
context.getRegistry()).getRegistry()).bind("amazonSQSClient", mock);
SqsComponent component = new SqsComponent(context);
-SqsEndpoint endpoint = (SqsEndpoint)
component.createEndpoint("aws-sqs://arn:aws:sqs:region:account:MyQueue?amazonSQSClient=#amazonSQSClient&accessKey=xxx&secretKey=yyy");
+SqsEndpoint endpoint = (SqsEndpoint)
component.createEndpoint("aws-sqs://arn:aws:sqs:region:account:MyQueue?amazonSQSClient=#amazonSQSClient&accessKey=xxx&secretKey=yyy®ion=US_EAST_2");
-assertEquals("region", endpoint.getConfiguration().getRegion());
Review comment:
Region value was taken from ARN which is wrong. Take a look at the source
file changes.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Problem in setting region for camel AWS-SQS endpoint
>
>
> Key: CAMEL-12647
> URL: https://issues.apache.org/jira/browse/CAMEL-12647
> Project: Camel
> Issue Type: Bug
> Components: camel-aws
>Affects Versions: 2.21.1
>Reporter: Saravanakumar Selvaraj
>Priority: Major
>
> It gives FailedToCreateRouteException while creating camel AWS-SQS endpoint
> with ARN.
> For example, below producer or consumer endpoint is not being created.
> {code:java}
> uri="aws-sqs://arn:aws:sqs:us-east-2:account:MyQueue?accessKey=xxx&secretKey=yyy®ion=US_EAST_2"{code}
> And it throws error as follows.
> {code:java}
> Caused by: java.lang.IllegalArgumentException: No enum constant
> com.amazonaws.regions.Regions.us-east-2
> at java.lang.Enum.valueOf(Enum.java:238)
> at com.amazonaws.regions.Regions.valueOf(Regions.java:26)
> at
> org.apache.camel.component.aws.sqs.SqsEndpoint.createClient(SqsEndpoint.java:310)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CAMEL-12647) Problem in setting region for camel AWS-SQS endpoint
[
https://issues.apache.org/jira/browse/CAMEL-12647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16542537#comment-16542537
]
ASF GitHub Bot commented on CAMEL-12647:
saravanakumar1987 commented on a change in pull request #2424: CAMEL-12647 :
Problem in setting region for camel AWS-SQS endpoint
URL: https://github.com/apache/camel/pull/2424#discussion_r202246177
##
File path:
components/camel-aws/src/test/java/org/apache/camel/component/aws/sqs/SqsComponentConfigurationTest.java
##
@@ -73,9 +73,9 @@ public void createEndpointWithMinimalArnConfiguration()
throws Exception {
((JndiRegistry) ((PropertyPlaceholderDelegateRegistry)
context.getRegistry()).getRegistry()).bind("amazonSQSClient", mock);
SqsComponent component = new SqsComponent(context);
-SqsEndpoint endpoint = (SqsEndpoint)
component.createEndpoint("aws-sqs://arn:aws:sqs:region:account:MyQueue?amazonSQSClient=#amazonSQSClient&accessKey=xxx&secretKey=yyy");
+SqsEndpoint endpoint = (SqsEndpoint)
component.createEndpoint("aws-sqs://arn:aws:sqs:region:account:MyQueue?amazonSQSClient=#amazonSQSClient&accessKey=xxx&secretKey=yyy®ion=US_EAST_2");
-assertEquals("region", endpoint.getConfiguration().getRegion());
Review comment:
Region value was taken from ARN which was wrong. Take a look at the source
file changes.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Problem in setting region for camel AWS-SQS endpoint
>
>
> Key: CAMEL-12647
> URL: https://issues.apache.org/jira/browse/CAMEL-12647
> Project: Camel
> Issue Type: Bug
> Components: camel-aws
>Affects Versions: 2.21.1
>Reporter: Saravanakumar Selvaraj
>Priority: Major
>
> It gives FailedToCreateRouteException while creating camel AWS-SQS endpoint
> with ARN.
> For example, below producer or consumer endpoint is not being created.
> {code:java}
> uri="aws-sqs://arn:aws:sqs:us-east-2:account:MyQueue?accessKey=xxx&secretKey=yyy®ion=US_EAST_2"{code}
> And it throws error as follows.
> {code:java}
> Caused by: java.lang.IllegalArgumentException: No enum constant
> com.amazonaws.regions.Regions.us-east-2
> at java.lang.Enum.valueOf(Enum.java:238)
> at com.amazonaws.regions.Regions.valueOf(Regions.java:26)
> at
> org.apache.camel.component.aws.sqs.SqsEndpoint.createClient(SqsEndpoint.java:310)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CAMEL-12647) Problem in setting region for camel AWS-SQS endpoint
[
https://issues.apache.org/jira/browse/CAMEL-12647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16542531#comment-16542531
]
ASF GitHub Bot commented on CAMEL-12647:
onderson commented on a change in pull request #2424: CAMEL-12647 : Problem in
setting region for camel AWS-SQS endpoint
URL: https://github.com/apache/camel/pull/2424#discussion_r202245127
##
File path:
components/camel-aws/src/test/java/org/apache/camel/component/aws/sqs/SqsComponentConfigurationTest.java
##
@@ -73,9 +73,9 @@ public void createEndpointWithMinimalArnConfiguration()
throws Exception {
((JndiRegistry) ((PropertyPlaceholderDelegateRegistry)
context.getRegistry()).getRegistry()).bind("amazonSQSClient", mock);
SqsComponent component = new SqsComponent(context);
-SqsEndpoint endpoint = (SqsEndpoint)
component.createEndpoint("aws-sqs://arn:aws:sqs:region:account:MyQueue?amazonSQSClient=#amazonSQSClient&accessKey=xxx&secretKey=yyy");
+SqsEndpoint endpoint = (SqsEndpoint)
component.createEndpoint("aws-sqs://arn:aws:sqs:region:account:MyQueue?amazonSQSClient=#amazonSQSClient&accessKey=xxx&secretKey=yyy®ion=US_EAST_2");
-assertEquals("region", endpoint.getConfiguration().getRegion());
Review comment:
Should not this assert be null before this change?
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Problem in setting region for camel AWS-SQS endpoint
>
>
> Key: CAMEL-12647
> URL: https://issues.apache.org/jira/browse/CAMEL-12647
> Project: Camel
> Issue Type: Bug
> Components: camel-aws
>Affects Versions: 2.21.1
>Reporter: Saravanakumar Selvaraj
>Priority: Major
>
> It gives FailedToCreateRouteException while creating camel AWS-SQS endpoint
> with ARN.
> For example, below producer or consumer endpoint is not being created.
> {code:java}
> uri="aws-sqs://arn:aws:sqs:us-east-2:account:MyQueue?accessKey=xxx&secretKey=yyy®ion=US_EAST_2"{code}
> And it throws error as follows.
> {code:java}
> Caused by: java.lang.IllegalArgumentException: No enum constant
> com.amazonaws.regions.Regions.us-east-2
> at java.lang.Enum.valueOf(Enum.java:238)
> at com.amazonaws.regions.Regions.valueOf(Regions.java:26)
> at
> org.apache.camel.component.aws.sqs.SqsEndpoint.createClient(SqsEndpoint.java:310)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CAMEL-12648) ExchangeSentEvent not fired if no EventNotifier is accepting ExchangeSendingEvent
Kevin Garner created CAMEL-12648: Summary: ExchangeSentEvent not fired if no EventNotifier is accepting ExchangeSendingEvent Key: CAMEL-12648 URL: https://issues.apache.org/jira/browse/CAMEL-12648 Project: Camel Issue Type: Bug Components: camel-core Affects Versions: 2.21.0, 2.20.0, 2.22.0 Reporter: Kevin Garner Due to changes in CAMEL-11346, many processors (including SendProcessor) no longer send ExchangeSentEvent when processing is done. The StopWatch object is not created when EventHelper.notifyExchangeSending returns false. If no EventNotifier is registered to receive that event, it will be false. But an EventNotifier may still be registered to receive ExchangeSentEvent. The StopWatch should be created when there is an EventNotifier registered for ExchangeSentEvent even when ExchangeSendingEvent is not, unless those events are always required to be paired together. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CAMEL-12647) Problem in setting region for camel AWS-SQS endpoint
[
https://issues.apache.org/jira/browse/CAMEL-12647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16542227#comment-16542227
]
ASF GitHub Bot commented on CAMEL-12647:
GitHub user saravanakumar1987 opened a pull request:
https://github.com/apache/camel/pull/2424
CAMEL-12647 : Problem in setting region for camel AWS-SQS endpoint
PR created for Bug : https://issues.apache.org/jira/browse/CAMEL-12647
Thanks,
Saravanakumar
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/saravanakumar1987/camel master
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/camel/pull/2424.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #2424
commit 9a2ce74a208f8df622536202acf3c2e26ef417a6
Author: Saravanakumar Selvaraj
Date: 2018-07-12T21:40:57Z
CAMEL-12647 : Problem in setting region for camel AWS-SQS endpoint
> Problem in setting region for camel AWS-SQS endpoint
>
>
> Key: CAMEL-12647
> URL: https://issues.apache.org/jira/browse/CAMEL-12647
> Project: Camel
> Issue Type: Bug
> Components: camel-aws
>Affects Versions: 2.21.1
>Reporter: Saravanakumar Selvaraj
>Priority: Major
>
> It gives FailedToCreateRouteException while creating camel AWS-SQS endpoint
> with ARN.
> For example, below producer or consumer endpoint is not being created.
> {code:java}
> uri="aws-sqs://arn:aws:sqs:us-east-2:account:MyQueue?accessKey=xxx&secretKey=yyy®ion=US_EAST_2"{code}
> And it throws error as follows.
> {code:java}
> Caused by: java.lang.IllegalArgumentException: No enum constant
> com.amazonaws.regions.Regions.us-east-2
> at java.lang.Enum.valueOf(Enum.java:238)
> at com.amazonaws.regions.Regions.valueOf(Regions.java:26)
> at
> org.apache.camel.component.aws.sqs.SqsEndpoint.createClient(SqsEndpoint.java:310)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CAMEL-12647) Problem in setting region for camel AWS-SQS endpoint
[
https://issues.apache.org/jira/browse/CAMEL-12647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16542226#comment-16542226
]
ASF GitHub Bot commented on CAMEL-12647:
saravanakumar1987 opened a new pull request #2424: CAMEL-12647 : Problem in
setting region for camel AWS-SQS endpoint
URL: https://github.com/apache/camel/pull/2424
PR created for Bug : https://issues.apache.org/jira/browse/CAMEL-12647
Thanks,
Saravanakumar
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Problem in setting region for camel AWS-SQS endpoint
>
>
> Key: CAMEL-12647
> URL: https://issues.apache.org/jira/browse/CAMEL-12647
> Project: Camel
> Issue Type: Bug
> Components: camel-aws
>Affects Versions: 2.21.1
>Reporter: Saravanakumar Selvaraj
>Priority: Major
>
> It gives FailedToCreateRouteException while creating camel AWS-SQS endpoint
> with ARN.
> For example, below producer or consumer endpoint is not being created.
> {code:java}
> uri="aws-sqs://arn:aws:sqs:us-east-2:account:MyQueue?accessKey=xxx&secretKey=yyy®ion=US_EAST_2"{code}
> And it throws error as follows.
> {code:java}
> Caused by: java.lang.IllegalArgumentException: No enum constant
> com.amazonaws.regions.Regions.us-east-2
> at java.lang.Enum.valueOf(Enum.java:238)
> at com.amazonaws.regions.Regions.valueOf(Regions.java:26)
> at
> org.apache.camel.component.aws.sqs.SqsEndpoint.createClient(SqsEndpoint.java:310)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CAMEL-12647) Problem in setting region for camel AWS-SQS endpoint
Saravanakumar Selvaraj created CAMEL-12647:
--
Summary: Problem in setting region for camel AWS-SQS endpoint
Key: CAMEL-12647
URL: https://issues.apache.org/jira/browse/CAMEL-12647
Project: Camel
Issue Type: Bug
Components: camel-aws
Affects Versions: 2.21.1
Reporter: Saravanakumar Selvaraj
It gives FailedToCreateRouteException while creating camel AWS-SQS endpoint
with ARN.
For example, below producer or consumer endpoint is not being created.
{code:java}
uri="aws-sqs://arn:aws:sqs:us-east-2:account:MyQueue?accessKey=xxx&secretKey=yyy®ion=US_EAST_2"{code}
And it throws error as follows.
{code:java}
Caused by: java.lang.IllegalArgumentException: No enum constant
com.amazonaws.regions.Regions.us-east-2
at java.lang.Enum.valueOf(Enum.java:238)
at com.amazonaws.regions.Regions.valueOf(Regions.java:26)
at
org.apache.camel.component.aws.sqs.SqsEndpoint.createClient(SqsEndpoint.java:310)
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CAMEL-12643) camel-rabbitmq - Inadequate information for handling catch clauses
[
https://issues.apache.org/jira/browse/CAMEL-12643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16542008#comment-16542008
]
ASF GitHub Bot commented on CAMEL-12643:
lzh3636 commented on issue #2422: CAMEL-12643: Inadequate information for
handling catch clauses
URL: https://github.com/apache/camel/pull/2422#issuecomment-404593890
Okay, thanks!
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> camel-rabbitmq - Inadequate information for handling catch clauses
> --
>
> Key: CAMEL-12643
> URL: https://issues.apache.org/jira/browse/CAMEL-12643
> Project: Camel
> Issue Type: Improvement
> Components: camel-rabbitmq
>Reporter: Zhenhao Li
>Priority: Minor
>
> There are some situations that different exception types are caught, but the
> handling of those exceptions cannot show the differences between those types.
> Here are the code snippets which have this problem:
> {code}
> org.apache.camel.component.rabbitmq.*RabbitConsumer*.handleShutdownSignal,
> *Line 271*
> catch (IOException | TimeoutException e)
> { log.warn("Unable to obtain a RabbitMQ channel. Will try again"); ...
> }
> {code}
> It may cause confusions to the person who is reading the log, the person can
> not know what exception happened here and cannot distinguish if the exception
> type is IOException or TimeoutException. Simply adding a full stack trace is
> able to improve it.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CAMEL-12644) Generate documentation for Spring Boot starters
[ https://issues.apache.org/jira/browse/CAMEL-12644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16541911#comment-16541911 ] Andrea Cosentino commented on CAMEL-12644: -- Good idea. > Generate documentation for Spring Boot starters > --- > > Key: CAMEL-12644 > URL: https://issues.apache.org/jira/browse/CAMEL-12644 > Project: Camel > Issue Type: New Feature > Components: camel-spring-boot-starters, documentation >Reporter: Zoran Regvart >Priority: Major > Fix For: 2.23.0 > > > We could add auto-configuration properties section to the component > documentation something like that can be seen in the [spring-boot > documentation|https://docs.spring.io/spring-boot/docs/1.5.14.RELEASE/reference/htmlsingle/#common-application-properties] > to help the users know which properties are available in > application.[properties|yaml] under what keys. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CAMEL-12568) camel-univocity-parsers: Upgrade to version 2.6.4 once released
[ https://issues.apache.org/jira/browse/CAMEL-12568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrea Cosentino resolved CAMEL-12568. -- Resolution: Fixed > camel-univocity-parsers: Upgrade to version 2.6.4 once released > --- > > Key: CAMEL-12568 > URL: https://issues.apache.org/jira/browse/CAMEL-12568 > Project: Camel > Issue Type: Bug >Affects Versions: 2.22.0 >Reporter: Alex Dettinger >Assignee: Andrea Cosentino >Priority: Minor > Fix For: 2.22.0 > > > Version 2.6.4 would contain a lot of bug fixes. And correct a regression that > prevented the upgrade to univocity-parsers 2.4.0. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CAMEL-12638) DefaultFluentProducerTemplate is not thread safe
[
https://issues.apache.org/jira/browse/CAMEL-12638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Papandrea updated CAMEL-12638:
Attachment: (was: image-2018-07-12-17-56-23-086.png)
> DefaultFluentProducerTemplate is not thread safe
>
>
> Key: CAMEL-12638
> URL: https://issues.apache.org/jira/browse/CAMEL-12638
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 2.20.2
>Reporter: Lukasz
>Priority: Major
> Attachments: image-2018-07-12-17-58-09-225.png
>
>
> I think we have rediscovered the CAMEL-10820 bug. A body of one request gets
> replaced with a body of proceeding request, in our case we use *request()*
> method instead of *asyncSend()*.
> We use camel together with spring-boot. Consider following code:
>
> {code:java}
> @Service
> public class UseCamelService {
>private FluentProducerTemplate producer;
>@Autowired
>public UseCamelService(FluentProducerTemplate producer) {
> this.producer = producer;
>}
>public String getValueFromCamel(String body) {
> return producer.to("route").withBody(body).request(String.class);
>}
> }
> {code}
> If *UseCamelService.getValueFromCamel()* gets called from two different
> threads it is possible for the latter one to override the body of the first
> one.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CAMEL-12638) DefaultFluentProducerTemplate is not thread safe
[
https://issues.apache.org/jira/browse/CAMEL-12638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Papandrea updated CAMEL-12638:
Attachment: (was: image-2018-07-12-17-57-11-867.png)
> DefaultFluentProducerTemplate is not thread safe
>
>
> Key: CAMEL-12638
> URL: https://issues.apache.org/jira/browse/CAMEL-12638
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 2.20.2
>Reporter: Lukasz
>Priority: Major
> Attachments: image-2018-07-12-17-58-09-225.png
>
>
> I think we have rediscovered the CAMEL-10820 bug. A body of one request gets
> replaced with a body of proceeding request, in our case we use *request()*
> method instead of *asyncSend()*.
> We use camel together with spring-boot. Consider following code:
>
> {code:java}
> @Service
> public class UseCamelService {
>private FluentProducerTemplate producer;
>@Autowired
>public UseCamelService(FluentProducerTemplate producer) {
> this.producer = producer;
>}
>public String getValueFromCamel(String body) {
> return producer.to("route").withBody(body).request(String.class);
>}
> }
> {code}
> If *UseCamelService.getValueFromCamel()* gets called from two different
> threads it is possible for the latter one to override the body of the first
> one.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CAMEL-12644) Generate documentation for Spring Boot starters
[ https://issues.apache.org/jira/browse/CAMEL-12644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16541893#comment-16541893 ] Claus Ibsen commented on CAMEL-12644: - Yeah this is a good idea, to have auto-generated in the .adoc files. We could maybe parse the target/classes/META-INF/spring-configuration-metadata.json files that spring-boot generates for all the -starer JARs. As that would be the options spring-boot supports. If we just repeat the component options we get 95% of them also, but there are some corner-cases where a component may have nested options like camel-docker-starter. > Generate documentation for Spring Boot starters > --- > > Key: CAMEL-12644 > URL: https://issues.apache.org/jira/browse/CAMEL-12644 > Project: Camel > Issue Type: New Feature > Components: camel-spring-boot-starters, documentation >Reporter: Zoran Regvart >Priority: Major > Fix For: 2.23.0 > > > We could add auto-configuration properties section to the component > documentation something like that can be seen in the [spring-boot > documentation|https://docs.spring.io/spring-boot/docs/1.5.14.RELEASE/reference/htmlsingle/#common-application-properties] > to help the users know which properties are available in > application.[properties|yaml] under what keys. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CAMEL-12644) Generate documentation for Spring Boot starters
[ https://issues.apache.org/jira/browse/CAMEL-12644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-12644: Component/s: documentation > Generate documentation for Spring Boot starters > --- > > Key: CAMEL-12644 > URL: https://issues.apache.org/jira/browse/CAMEL-12644 > Project: Camel > Issue Type: New Feature > Components: camel-spring-boot-starters, documentation >Reporter: Zoran Regvart >Priority: Major > Fix For: 2.23.0 > > > We could add auto-configuration properties section to the component > documentation something like that can be seen in the [spring-boot > documentation|https://docs.spring.io/spring-boot/docs/1.5.14.RELEASE/reference/htmlsingle/#common-application-properties] > to help the users know which properties are available in > application.[properties|yaml] under what keys. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CAMEL-12644) Generate documentation for Spring Boot starters
[ https://issues.apache.org/jira/browse/CAMEL-12644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-12644: Fix Version/s: 2.23.0 > Generate documentation for Spring Boot starters > --- > > Key: CAMEL-12644 > URL: https://issues.apache.org/jira/browse/CAMEL-12644 > Project: Camel > Issue Type: New Feature > Components: camel-spring-boot-starters, documentation >Reporter: Zoran Regvart >Priority: Major > Fix For: 2.23.0 > > > We could add auto-configuration properties section to the component > documentation something like that can be seen in the [spring-boot > documentation|https://docs.spring.io/spring-boot/docs/1.5.14.RELEASE/reference/htmlsingle/#common-application-properties] > to help the users know which properties are available in > application.[properties|yaml] under what keys. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CAMEL-12643) camel-rabbitmq - Inadequate information for handling catch clauses
[
https://issues.apache.org/jira/browse/CAMEL-12643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16541865#comment-16541865
]
ASF GitHub Bot commented on CAMEL-12643:
davsclaus commented on issue #2422: CAMEL-12643: Inadequate information for
handling catch clauses
URL: https://github.com/apache/camel/pull/2422#issuecomment-404565082
The + on the string concat can likely be merged into the other, and also we
can log the stacktrace at DEBUG level, and say that in the WARN message - that
is something we do in other places sometimes.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> camel-rabbitmq - Inadequate information for handling catch clauses
> --
>
> Key: CAMEL-12643
> URL: https://issues.apache.org/jira/browse/CAMEL-12643
> Project: Camel
> Issue Type: Improvement
> Components: camel-rabbitmq
>Reporter: Zhenhao Li
>Priority: Minor
>
> There are some situations that different exception types are caught, but the
> handling of those exceptions cannot show the differences between those types.
> Here are the code snippets which have this problem:
> {code}
> org.apache.camel.component.rabbitmq.*RabbitConsumer*.handleShutdownSignal,
> *Line 271*
> catch (IOException | TimeoutException e)
> { log.warn("Unable to obtain a RabbitMQ channel. Will try again"); ...
> }
> {code}
> It may cause confusions to the person who is reading the log, the person can
> not know what exception happened here and cannot distinguish if the exception
> type is IOException or TimeoutException. Simply adding a full stack trace is
> able to improve it.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (CAMEL-12638) DefaultFluentProducerTemplate is not thread safe
[
https://issues.apache.org/jira/browse/CAMEL-12638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16541858#comment-16541858
]
Mario Papandrea edited comment on CAMEL-12638 at 7/12/18 3:58 PM:
--
Moreover the api doc clearly state that this object is "thread safe"
[http://static.javadoc.io/org.apache.camel/camel-core/2.19.3/org/apache/camel/FluentProducerTemplate.html]
!image-2018-07-12-17-58-09-225.png!
was (Author: mario.papandrea):
Moreover the api doc clearly state that this object is "thread safe"
[http://static.javadoc.io/org.apache.camel/camel-core/2.19.3/org/apache/camel/FluentProducerTemplate.html]
!image-2018-07-12-17-57-11-867.png!
> DefaultFluentProducerTemplate is not thread safe
>
>
> Key: CAMEL-12638
> URL: https://issues.apache.org/jira/browse/CAMEL-12638
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 2.20.2
>Reporter: Lukasz
>Priority: Major
> Attachments: image-2018-07-12-17-56-23-086.png,
> image-2018-07-12-17-57-11-867.png, image-2018-07-12-17-58-09-225.png
>
>
> I think we have rediscovered the CAMEL-10820 bug. A body of one request gets
> replaced with a body of proceeding request, in our case we use *request()*
> method instead of *asyncSend()*.
> We use camel together with spring-boot. Consider following code:
>
> {code:java}
> @Service
> public class UseCamelService {
>private FluentProducerTemplate producer;
>@Autowired
>public UseCamelService(FluentProducerTemplate producer) {
> this.producer = producer;
>}
>public String getValueFromCamel(String body) {
> return producer.to("route").withBody(body).request(String.class);
>}
> }
> {code}
> If *UseCamelService.getValueFromCamel()* gets called from two different
> threads it is possible for the latter one to override the body of the first
> one.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CAMEL-12638) DefaultFluentProducerTemplate is not thread safe
[
https://issues.apache.org/jira/browse/CAMEL-12638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Papandrea updated CAMEL-12638:
Attachment: image-2018-07-12-17-57-11-867.png
> DefaultFluentProducerTemplate is not thread safe
>
>
> Key: CAMEL-12638
> URL: https://issues.apache.org/jira/browse/CAMEL-12638
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 2.20.2
>Reporter: Lukasz
>Priority: Major
> Attachments: image-2018-07-12-17-56-23-086.png,
> image-2018-07-12-17-57-11-867.png
>
>
> I think we have rediscovered the CAMEL-10820 bug. A body of one request gets
> replaced with a body of proceeding request, in our case we use *request()*
> method instead of *asyncSend()*.
> We use camel together with spring-boot. Consider following code:
>
> {code:java}
> @Service
> public class UseCamelService {
>private FluentProducerTemplate producer;
>@Autowired
>public UseCamelService(FluentProducerTemplate producer) {
> this.producer = producer;
>}
>public String getValueFromCamel(String body) {
> return producer.to("route").withBody(body).request(String.class);
>}
> }
> {code}
> If *UseCamelService.getValueFromCamel()* gets called from two different
> threads it is possible for the latter one to override the body of the first
> one.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CAMEL-12638) DefaultFluentProducerTemplate is not thread safe
[
https://issues.apache.org/jira/browse/CAMEL-12638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16541858#comment-16541858
]
Mario Papandrea commented on CAMEL-12638:
-
Moreover the api doc clearly state that this object is "thread safe"
[http://static.javadoc.io/org.apache.camel/camel-core/2.19.3/org/apache/camel/FluentProducerTemplate.html]
!image-2018-07-12-17-57-11-867.png!
> DefaultFluentProducerTemplate is not thread safe
>
>
> Key: CAMEL-12638
> URL: https://issues.apache.org/jira/browse/CAMEL-12638
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 2.20.2
>Reporter: Lukasz
>Priority: Major
> Attachments: image-2018-07-12-17-56-23-086.png,
> image-2018-07-12-17-57-11-867.png
>
>
> I think we have rediscovered the CAMEL-10820 bug. A body of one request gets
> replaced with a body of proceeding request, in our case we use *request()*
> method instead of *asyncSend()*.
> We use camel together with spring-boot. Consider following code:
>
> {code:java}
> @Service
> public class UseCamelService {
>private FluentProducerTemplate producer;
>@Autowired
>public UseCamelService(FluentProducerTemplate producer) {
> this.producer = producer;
>}
>public String getValueFromCamel(String body) {
> return producer.to("route").withBody(body).request(String.class);
>}
> }
> {code}
> If *UseCamelService.getValueFromCamel()* gets called from two different
> threads it is possible for the latter one to override the body of the first
> one.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CAMEL-12638) DefaultFluentProducerTemplate is not thread safe
[
https://issues.apache.org/jira/browse/CAMEL-12638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Papandrea updated CAMEL-12638:
Attachment: image-2018-07-12-17-56-23-086.png
> DefaultFluentProducerTemplate is not thread safe
>
>
> Key: CAMEL-12638
> URL: https://issues.apache.org/jira/browse/CAMEL-12638
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 2.20.2
>Reporter: Lukasz
>Priority: Major
> Attachments: image-2018-07-12-17-56-23-086.png
>
>
> I think we have rediscovered the CAMEL-10820 bug. A body of one request gets
> replaced with a body of proceeding request, in our case we use *request()*
> method instead of *asyncSend()*.
> We use camel together with spring-boot. Consider following code:
>
> {code:java}
> @Service
> public class UseCamelService {
>private FluentProducerTemplate producer;
>@Autowired
>public UseCamelService(FluentProducerTemplate producer) {
> this.producer = producer;
>}
>public String getValueFromCamel(String body) {
> return producer.to("route").withBody(body).request(String.class);
>}
> }
> {code}
> If *UseCamelService.getValueFromCamel()* gets called from two different
> threads it is possible for the latter one to override the body of the first
> one.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (CAMEL-12638) DefaultFluentProducerTemplate is not thread safe
[
https://issues.apache.org/jira/browse/CAMEL-12638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16541562#comment-16541562
]
Lukasz edited comment on CAMEL-12638 at 7/12/18 3:52 PM:
-
I'm not really convinced by that [~njiang]. Even in the _Camel in Action
(Second Edition)_ book, [~davsclaus] and [~janstey] use it as a standard bean
that can be called to execute a service, not as a builder (see _Listing 7.12
JAX-RS_ _REST implementation_)_:_
{code:java}
@ApplicationScoped
@Path ( "/api" )
public class RulesController {
@Inject
@Uri ( "direct:inventory" )
private FluentProducerTemplate producer;
@GET
@Produces ( MediaType.APPLICATION_JSON )
@Path ( "/rules/{cartIds}" )
public List rules( @PathParam ( "cartIds" ) String cartIds ) {
List answer = new ArrayList<>();
ItemsDto inventory = producer.request( ItemsDto.class );
[...]
}
}{code}
Obviously they don't refer to a specific implementation but we can all imagine
which implementation is provided by default. Also if it was supposed to be
*just* a builder I find it misleading that the class actually implements a
_Service_ interface.
was (Author: lucas_):
I'm not really convinced by that [~njiang]. Even in the _Camel in Action
(Second Edition)_ book, [~cib...@e-ma.net] and [~janstey] use it as a standard
bean that can be called to execute a service, not as a builder (see _Listing
7.12 JAX-RS_ _REST implementation_)_:_
{code:java}
@ApplicationScoped
@Path ( "/api" )
public class RulesController {
@Inject
@Uri ( "direct:inventory" )
private FluentProducerTemplate producer;
@GET
@Produces ( MediaType.APPLICATION_JSON )
@Path ( "/rules/{cartIds}" )
public List rules( @PathParam ( "cartIds" ) String cartIds ) {
List answer = new ArrayList<>();
ItemsDto inventory = producer.request( ItemsDto.class );
[...]
}
}{code}
Obviously they don't refer to a specific implementation but we can all imagine
which implementation is provided by default. Also if it was supposed to be
*just* a builder I find it misleading that the class actually implements a
_Service_ interface.
> DefaultFluentProducerTemplate is not thread safe
>
>
> Key: CAMEL-12638
> URL: https://issues.apache.org/jira/browse/CAMEL-12638
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 2.20.2
>Reporter: Lukasz
>Priority: Major
>
> I think we have rediscovered the CAMEL-10820 bug. A body of one request gets
> replaced with a body of proceeding request, in our case we use *request()*
> method instead of *asyncSend()*.
> We use camel together with spring-boot. Consider following code:
>
> {code:java}
> @Service
> public class UseCamelService {
>private FluentProducerTemplate producer;
>@Autowired
>public UseCamelService(FluentProducerTemplate producer) {
> this.producer = producer;
>}
>public String getValueFromCamel(String body) {
> return producer.to("route").withBody(body).request(String.class);
>}
> }
> {code}
> If *UseCamelService.getValueFromCamel()* gets called from two different
> threads it is possible for the latter one to override the body of the first
> one.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CAMEL-12646) camel-spring-boot - Auto configuration of complex types should be more tooling friendly
[ https://issues.apache.org/jira/browse/CAMEL-12646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16541845#comment-16541845 ] ASF GitHub Bot commented on CAMEL-12646: GitHub user davsclaus opened a pull request: https://github.com/apache/camel/pull/2423 Camel 12646 - camel-spring-boot - Auto configuration of complex types should be more tooling friendly The camel maven plugin for spring boot auto configuration source code generation now generates complex types as String types so we can use them via spring boot and its tooling, eg they are listed in the spring-configuration-metadata.json file. See ticket: https://issues.apache.org/jira/browse/CAMEL-12646 You can merge this pull request into a Git repository by running: $ git pull https://github.com/apache/camel camel-12646 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/camel/pull/2423.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #2423 commit 4dfc9f30d9002c06ae496cca997a5265e2cab262 Author: Claus Ibsen Date: 2018-07-12T13:24:46Z CAMEL-12464: camel maven plugin for spring-boot auto configuration polished. commit 2b4e3cf5d625f88c0d01a5cc1730954aaec9f7a4 Author: Claus Ibsen Date: 2018-07-12T14:05:47Z CAMEL-12646: The camel maven plugin for spring boot auto configuration source code generation now generates complex types as String types so we can use them via spring boot and its tooling, eg they are listed in the spring-configuration-metadata.json file. commit bd51298fe84ebcdd020ac93a0c8bbf1e581eded6 Author: Claus Ibsen Date: 2018-07-12T14:52:51Z CAMEL-12646: The camel maven plugin for spring boot auto configuration source code generation now generates complex types as String types so we can use them via spring boot and its tooling, eg they are listed in the spring-configuration-metadata.json file. > camel-spring-boot - Auto configuration of complex types should be more > tooling friendly > --- > > Key: CAMEL-12646 > URL: https://issues.apache.org/jira/browse/CAMEL-12646 > Project: Camel > Issue Type: Improvement > Components: camel-spring-boot-starters, tooling >Reporter: Claus Ibsen >Assignee: Claus Ibsen >Priority: Major > Fix For: 2.23.0 > > Attachments: Screen Shot 2018-07-12 at 17.43.41.png > > > If you have complex types like javax.sql.DataSource and wants to allow to > configure this via spring boot autoconfiguration in application.properties - > then the generated spring boot classes with all the options will use > getter/setter of types javax.sql.DataSource. That seems correct, but the > spring-boot tooling itself (that generates additional json file) will skip > those as it only support primitives and string types. > So we may need to fool, and generate the getter/setter as String type as you > use it for configuring it as a bean reference by id anyway, eg > camel.component.jdbc.data-source = #myDataSource > We can add in the javadoc that the type is javax.sql.DataSource. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CAMEL-12646) camel-spring-boot - Auto configuration of complex types should be more tooling friendly
[
https://issues.apache.org/jira/browse/CAMEL-12646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16541835#comment-16541835
]
Claus Ibsen commented on CAMEL-12646:
-
The screenshot shows now with the data-source included, and so in the generated
file by spring-boot
{code:java}
"properties": [
{
"sourceType":
"org.apache.camel.spring.boot.ComponentConfigurationPropertiesCommon$CustomizerProperties",
"name": "camel.component.jdbc.customizer.enabled",
"type": "java.lang.Boolean"
},
{
"sourceType":
"org.apache.camel.component.jdbc.springboot.JdbcComponentConfiguration",
"name": "camel.component.jdbc.data-source",
"description": "To use the DataSource instance instead of looking up the
data source by\n name from the registry. The option is a javax.sql.DataSource
type.",
"type": "java.lang.String"
},
{
"sourceType":
"org.apache.camel.component.jdbc.springboot.JdbcComponentConfiguration",
"defaultValue": true,
"name": "camel.component.jdbc.enabled",
"description": "Enable jdbc component",
"type": "java.lang.Boolean"
},
{
"sourceType":
"org.apache.camel.component.jdbc.springboot.JdbcComponentConfiguration",
"defaultValue": true,
"name": "camel.component.jdbc.resolve-property-placeholders",
"description": "Whether the component should resolve property placeholders
on itself when\n starting. Only properties which are of String type can use
property\n placeholders.",
"type": "java.lang.Boolean"
}
]
{code}
> camel-spring-boot - Auto configuration of complex types should be more
> tooling friendly
> ---
>
> Key: CAMEL-12646
> URL: https://issues.apache.org/jira/browse/CAMEL-12646
> Project: Camel
> Issue Type: Improvement
> Components: camel-spring-boot-starters, tooling
>Reporter: Claus Ibsen
>Assignee: Claus Ibsen
>Priority: Major
> Fix For: 2.23.0
>
> Attachments: Screen Shot 2018-07-12 at 17.43.41.png
>
>
> If you have complex types like javax.sql.DataSource and wants to allow to
> configure this via spring boot autoconfiguration in application.properties -
> then the generated spring boot classes with all the options will use
> getter/setter of types javax.sql.DataSource. That seems correct, but the
> spring-boot tooling itself (that generates additional json file) will skip
> those as it only support primitives and string types.
> So we may need to fool, and generate the getter/setter as String type as you
> use it for configuring it as a bean reference by id anyway, eg
> camel.component.jdbc.data-source = #myDataSource
> We can add in the javadoc that the type is javax.sql.DataSource.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CAMEL-12646) camel-spring-boot - Auto configuration of complex types should be more tooling friendly
[ https://issues.apache.org/jira/browse/CAMEL-12646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-12646: Attachment: Screen Shot 2018-07-12 at 17.43.41.png > camel-spring-boot - Auto configuration of complex types should be more > tooling friendly > --- > > Key: CAMEL-12646 > URL: https://issues.apache.org/jira/browse/CAMEL-12646 > Project: Camel > Issue Type: Improvement > Components: camel-spring-boot-starters, tooling >Reporter: Claus Ibsen >Assignee: Claus Ibsen >Priority: Major > Fix For: 2.23.0 > > Attachments: Screen Shot 2018-07-12 at 17.43.41.png > > > If you have complex types like javax.sql.DataSource and wants to allow to > configure this via spring boot autoconfiguration in application.properties - > then the generated spring boot classes with all the options will use > getter/setter of types javax.sql.DataSource. That seems correct, but the > spring-boot tooling itself (that generates additional json file) will skip > those as it only support primitives and string types. > So we may need to fool, and generate the getter/setter as String type as you > use it for configuring it as a bean reference by id anyway, eg > camel.component.jdbc.data-source = #myDataSource > We can add in the javadoc that the type is javax.sql.DataSource. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (CAMEL-12638) DefaultFluentProducerTemplate is not thread safe
[
https://issues.apache.org/jira/browse/CAMEL-12638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16541562#comment-16541562
]
Lukasz edited comment on CAMEL-12638 at 7/12/18 2:56 PM:
-
I'm not really convinced by that [~njiang]. Even in the _Camel in Action
(Second Edition)_ book, [~cib...@e-ma.net] and [~janstey] use it as a standard
bean that can be called to execute a service, not as a builder (see _Listing
7.12 JAX-RS_
_REST implementation_)_:_
{code:java}
@ApplicationScoped
@Path ( "/api" )
public class RulesController {
@Inject
@Uri ( "direct:inventory" )
private FluentProducerTemplate producer;
@GET
@Produces ( MediaType.APPLICATION_JSON )
@Path ( "/rules/{cartIds}" )
public List rules( @PathParam ( "cartIds" ) String cartIds ) {
List answer = new ArrayList<>();
ItemsDto inventory = producer.request( ItemsDto.class );
[...]
}
}{code}
Obviously they don't refer to a specific implementation but we can all imagine
which implementation is provided by default. Also if it was supposed to be
*just* a builder I find it misleading that the class actually implements a
_Service_ interface.
was (Author: lucas_):
I'm not really convinced by that [~njiang]. Even in the _Camel in Action
(Second Edition)_ book, Claus and Jonathan use it a standard bean that can be
called to execute a service not a builder (see _Listing 7.12 JAX-RS_
_REST implementation_)_:_
{code:java}
@ApplicationScoped
@Path ( "/api" )
public class RulesController {
@Inject
@Uri ( "direct:inventory" )
private FluentProducerTemplate producer;
@GET
@Produces ( MediaType.APPLICATION_JSON )
@Path ( "/rules/{cartIds}" )
public List rules( @PathParam ( "cartIds" ) String cartIds ) {
List answer = new ArrayList<>();
ItemsDto inventory = producer.request( ItemsDto.class );
[...]
}
}{code}
Obviously they don't refer to a specific implementation but we can all imagine
which implementation is provided by default. Also if it was supposed to be
*just* a builder I find it misleading that the class actually implements a
_Service_ interface.
> DefaultFluentProducerTemplate is not thread safe
>
>
> Key: CAMEL-12638
> URL: https://issues.apache.org/jira/browse/CAMEL-12638
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 2.20.2
>Reporter: Lukasz
>Priority: Major
>
> I think we have rediscovered the CAMEL-10820 bug. A body of one request gets
> replaced with a body of proceeding request, in our case we use *request()*
> method instead of *asyncSend()*.
> We use camel together with spring-boot. Consider following code:
>
> {code:java}
> @Service
> public class UseCamelService {
>private FluentProducerTemplate producer;
>@Autowired
>public UseCamelService(FluentProducerTemplate producer) {
> this.producer = producer;
>}
>public String getValueFromCamel(String body) {
> return producer.to("route").withBody(body).request(String.class);
>}
> }
> {code}
> If *UseCamelService.getValueFromCamel()* gets called from two different
> threads it is possible for the latter one to override the body of the first
> one.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (CAMEL-12638) DefaultFluentProducerTemplate is not thread safe
[
https://issues.apache.org/jira/browse/CAMEL-12638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16541562#comment-16541562
]
Lukasz edited comment on CAMEL-12638 at 7/12/18 2:56 PM:
-
I'm not really convinced by that [~njiang]. Even in the _Camel in Action
(Second Edition)_ book, [~cib...@e-ma.net] and [~janstey] use it as a standard
bean that can be called to execute a service, not as a builder (see _Listing
7.12 JAX-RS_ _REST implementation_)_:_
{code:java}
@ApplicationScoped
@Path ( "/api" )
public class RulesController {
@Inject
@Uri ( "direct:inventory" )
private FluentProducerTemplate producer;
@GET
@Produces ( MediaType.APPLICATION_JSON )
@Path ( "/rules/{cartIds}" )
public List rules( @PathParam ( "cartIds" ) String cartIds ) {
List answer = new ArrayList<>();
ItemsDto inventory = producer.request( ItemsDto.class );
[...]
}
}{code}
Obviously they don't refer to a specific implementation but we can all imagine
which implementation is provided by default. Also if it was supposed to be
*just* a builder I find it misleading that the class actually implements a
_Service_ interface.
was (Author: lucas_):
I'm not really convinced by that [~njiang]. Even in the _Camel in Action
(Second Edition)_ book, [~cib...@e-ma.net] and [~janstey] use it as a standard
bean that can be called to execute a service, not as a builder (see _Listing
7.12 JAX-RS_
_REST implementation_)_:_
{code:java}
@ApplicationScoped
@Path ( "/api" )
public class RulesController {
@Inject
@Uri ( "direct:inventory" )
private FluentProducerTemplate producer;
@GET
@Produces ( MediaType.APPLICATION_JSON )
@Path ( "/rules/{cartIds}" )
public List rules( @PathParam ( "cartIds" ) String cartIds ) {
List answer = new ArrayList<>();
ItemsDto inventory = producer.request( ItemsDto.class );
[...]
}
}{code}
Obviously they don't refer to a specific implementation but we can all imagine
which implementation is provided by default. Also if it was supposed to be
*just* a builder I find it misleading that the class actually implements a
_Service_ interface.
> DefaultFluentProducerTemplate is not thread safe
>
>
> Key: CAMEL-12638
> URL: https://issues.apache.org/jira/browse/CAMEL-12638
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 2.20.2
>Reporter: Lukasz
>Priority: Major
>
> I think we have rediscovered the CAMEL-10820 bug. A body of one request gets
> replaced with a body of proceeding request, in our case we use *request()*
> method instead of *asyncSend()*.
> We use camel together with spring-boot. Consider following code:
>
> {code:java}
> @Service
> public class UseCamelService {
>private FluentProducerTemplate producer;
>@Autowired
>public UseCamelService(FluentProducerTemplate producer) {
> this.producer = producer;
>}
>public String getValueFromCamel(String body) {
> return producer.to("route").withBody(body).request(String.class);
>}
> }
> {code}
> If *UseCamelService.getValueFromCamel()* gets called from two different
> threads it is possible for the latter one to override the body of the first
> one.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CAMEL-12639) tooling - Provide line numbers for CamelEndpointDetails for java dsl
[ https://issues.apache.org/jira/browse/CAMEL-12639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16541746#comment-16541746 ] Aurélien Pupier commented on CAMEL-12639: - There are some test to check that the lineNumber is provided https://github.com/apache/camel/blob/6cd926eaae9b8cbed35f8016cf367098271819b0/tooling/camel-route-parser/src/test/java/org/apache/camel/parser/java/RoasterEndpointInjectTest.java#L40 We can notice that the line number end is not provided: !screenshot-2.png! > tooling - Provide line numbers for CamelEndpointDetails for java dsl > > > Key: CAMEL-12639 > URL: https://issues.apache.org/jira/browse/CAMEL-12639 > Project: Camel > Issue Type: Improvement > Components: tooling >Affects Versions: 2.22.0 >Reporter: Aurélien Pupier >Priority: Minor > Fix For: 2.23.0 > > Attachments: screenshot-1.png, screenshot-2.png > > > currently it is provided for xml dsl but not for java dsl -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CAMEL-12639) tooling - Provide line numbers for CamelEndpointDetails for java dsl
[ https://issues.apache.org/jira/browse/CAMEL-12639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aurélien Pupier updated CAMEL-12639: Attachment: screenshot-2.png > tooling - Provide line numbers for CamelEndpointDetails for java dsl > > > Key: CAMEL-12639 > URL: https://issues.apache.org/jira/browse/CAMEL-12639 > Project: Camel > Issue Type: Improvement > Components: tooling >Affects Versions: 2.22.0 >Reporter: Aurélien Pupier >Priority: Minor > Fix For: 2.23.0 > > Attachments: screenshot-1.png, screenshot-2.png > > > currently it is provided for xml dsl but not for java dsl -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CAMEL-12643) camel-rabbitmq - Inadequate information for handling catch clauses
[
https://issues.apache.org/jira/browse/CAMEL-12643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16541690#comment-16541690
]
ASF GitHub Bot commented on CAMEL-12643:
lzh3636 edited a comment on issue #2422: CAMEL-12643: Inadequate information
for handling catch clauses
URL: https://github.com/apache/camel/pull/2422#issuecomment-404522296
It's done, thanks! By the way, can I know that usually in what kind of
situations do you log the stack trace?
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> camel-rabbitmq - Inadequate information for handling catch clauses
> --
>
> Key: CAMEL-12643
> URL: https://issues.apache.org/jira/browse/CAMEL-12643
> Project: Camel
> Issue Type: Improvement
> Components: camel-rabbitmq
>Reporter: Zhenhao Li
>Priority: Minor
>
> There are some situations that different exception types are caught, but the
> handling of those exceptions cannot show the differences between those types.
> Here are the code snippets which have this problem:
> {code}
> org.apache.camel.component.rabbitmq.*RabbitConsumer*.handleShutdownSignal,
> *Line 271*
> catch (IOException | TimeoutException e)
> { log.warn("Unable to obtain a RabbitMQ channel. Will try again"); ...
> }
> {code}
> It may cause confusions to the person who is reading the log, the person can
> not know what exception happened here and cannot distinguish if the exception
> type is IOException or TimeoutException. Simply adding a full stack trace is
> able to improve it.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CAMEL-12643) camel-rabbitmq - Inadequate information for handling catch clauses
[
https://issues.apache.org/jira/browse/CAMEL-12643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16541686#comment-16541686
]
ASF GitHub Bot commented on CAMEL-12643:
lzh3636 commented on issue #2422: CAMEL-12643: Inadequate information for
handling catch clauses
URL: https://github.com/apache/camel/pull/2422#issuecomment-404522296
It's done, thanks! By the way, can I know that usually in which kind of
situations do you log the stack trace?
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> camel-rabbitmq - Inadequate information for handling catch clauses
> --
>
> Key: CAMEL-12643
> URL: https://issues.apache.org/jira/browse/CAMEL-12643
> Project: Camel
> Issue Type: Improvement
> Components: camel-rabbitmq
>Reporter: Zhenhao Li
>Priority: Minor
>
> There are some situations that different exception types are caught, but the
> handling of those exceptions cannot show the differences between those types.
> Here are the code snippets which have this problem:
> {code}
> org.apache.camel.component.rabbitmq.*RabbitConsumer*.handleShutdownSignal,
> *Line 271*
> catch (IOException | TimeoutException e)
> { log.warn("Unable to obtain a RabbitMQ channel. Will try again"); ...
> }
> {code}
> It may cause confusions to the person who is reading the log, the person can
> not know what exception happened here and cannot distinguish if the exception
> type is IOException or TimeoutException. Simply adding a full stack trace is
> able to improve it.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CAMEL-12643) camel-rabbitmq - Inadequate information for handling catch clauses
[
https://issues.apache.org/jira/browse/CAMEL-12643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Willem Jiang updated CAMEL-12643:
-
Description:
There are some situations that different exception types are caught, but the
handling of those exceptions cannot show the differences between those types.
Here are the code snippets which have this problem:
{code}
org.apache.camel.component.rabbitmq.*RabbitConsumer*.handleShutdownSignal,
*Line 271*
catch (IOException | TimeoutException e)
{ log.warn("Unable to obtain a RabbitMQ channel. Will try again"); ...
}
{code}
It may cause confusions to the person who is reading the log, the person can
not know what exception happened here and cannot distinguish if the exception
type is IOException or TimeoutException. Simply adding a full stack trace is
able to improve it.
was:
There are some situations that different exception types are caught, but the
handling of those exceptions cannot show the differences between those types.
Here are the code snippets which have this problem:
org.apache.camel.component.rabbitmq.*RabbitConsumer*.handleShutdownSignal,
*Line 271*
catch (IOException | TimeoutException e)
{ log.warn("Unable to obtain a RabbitMQ channel. Will try again"); ...
}
It may cause confusions to the person who is reading the log, the person can
not know what exception happened here and cannot distinguish if the exception
type is IOException or TimeoutException. Simply adding a full stack trace is
able to improve it.
> camel-rabbitmq - Inadequate information for handling catch clauses
> --
>
> Key: CAMEL-12643
> URL: https://issues.apache.org/jira/browse/CAMEL-12643
> Project: Camel
> Issue Type: Improvement
> Components: camel-rabbitmq
>Reporter: Zhenhao Li
>Priority: Minor
>
> There are some situations that different exception types are caught, but the
> handling of those exceptions cannot show the differences between those types.
> Here are the code snippets which have this problem:
> {code}
> org.apache.camel.component.rabbitmq.*RabbitConsumer*.handleShutdownSignal,
> *Line 271*
> catch (IOException | TimeoutException e)
> { log.warn("Unable to obtain a RabbitMQ channel. Will try again"); ...
> }
> {code}
> It may cause confusions to the person who is reading the log, the person can
> not know what exception happened here and cannot distinguish if the exception
> type is IOException or TimeoutException. Simply adding a full stack trace is
> able to improve it.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CAMEL-12549) Upgrade to Groovy 2.5
[ https://issues.apache.org/jira/browse/CAMEL-12549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16541655#comment-16541655 ] Willem Jiang commented on CAMEL-12549: -- With the mvn search we get the jar inforation. https://mvnrepository.com/artifact/org.codehaus.groovy/groovy/2.5.0 > Upgrade to Groovy 2.5 > - > > Key: CAMEL-12549 > URL: https://issues.apache.org/jira/browse/CAMEL-12549 > Project: Camel > Issue Type: Task > Components: camel-groovy >Reporter: Claus Ibsen >Priority: Minor > Fix For: 2.23.0 > > > Groovy 2.5 was just released. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CAMEL-12639) tooling - Provide line numbers for CamelEndpointDetails for java dsl
[ https://issues.apache.org/jira/browse/CAMEL-12639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16541652#comment-16541652 ] Aurélien Pupier commented on CAMEL-12639: - hum got it. i was providing a dummy path for the file as I have no File, I have only a String representing the whole file. So the feature request would be more to support parsing a String instead of a File. A workaround for me would be to write the File. > tooling - Provide line numbers for CamelEndpointDetails for java dsl > > > Key: CAMEL-12639 > URL: https://issues.apache.org/jira/browse/CAMEL-12639 > Project: Camel > Issue Type: Improvement > Components: tooling >Affects Versions: 2.22.0 >Reporter: Aurélien Pupier >Priority: Minor > Fix For: 2.23.0 > > Attachments: screenshot-1.png > > > currently it is provided for xml dsl but not for java dsl -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CAMEL-12639) tooling - Provide line numbers for CamelEndpointDetails for java dsl
[ https://issues.apache.org/jira/browse/CAMEL-12639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aurélien Pupier updated CAMEL-12639: Summary: tooling - Provide line numbers for CamelEndpointDetails for java dsl (was: tooling - Provide line numbers for validation result for java dsl) > tooling - Provide line numbers for CamelEndpointDetails for java dsl > > > Key: CAMEL-12639 > URL: https://issues.apache.org/jira/browse/CAMEL-12639 > Project: Camel > Issue Type: Improvement > Components: tooling >Affects Versions: 2.22.0 >Reporter: Aurélien Pupier >Priority: Minor > Fix For: 2.23.0 > > Attachments: screenshot-1.png > > > currently it is provided for xml dsl but not for java dsl -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CAMEL-12646) camel-spring-boot - Auto configuration of complex types should be more tooling friendly
[
https://issues.apache.org/jira/browse/CAMEL-12646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16541574#comment-16541574
]
Claus Ibsen commented on CAMEL-12646:
-
And these are the options in the spring-configuration-metadata.json file
{code:java}
"properties": [
{
"sourceType":
"org.apache.camel.spring.boot.ComponentConfigurationPropertiesCommon$CustomizerProperties",
"name": "camel.component.jdbc.customizer.enabled",
"type": "java.lang.Boolean"
},
{
"sourceType":
"org.apache.camel.component.jdbc.springboot.JdbcComponentConfiguration",
"defaultValue": true,
"name": "camel.component.jdbc.enabled",
"description": "Enable jdbc component",
"type": "java.lang.Boolean"
},
{
"sourceType":
"org.apache.camel.component.jdbc.springboot.JdbcComponentConfiguration",
"defaultValue": true,
"name": "camel.component.jdbc.resolve-property-placeholders",
"description": "Whether the component should resolve property placeholders
on itself when\n starting. Only properties which are of String type can use
property\n placeholders.",
"type": "java.lang.Boolean"
}
]
{code}
Notice how the dataSource option is missing.
> camel-spring-boot - Auto configuration of complex types should be more
> tooling friendly
> ---
>
> Key: CAMEL-12646
> URL: https://issues.apache.org/jira/browse/CAMEL-12646
> Project: Camel
> Issue Type: Improvement
> Components: camel-spring-boot-starters, tooling
>Reporter: Claus Ibsen
>Assignee: Claus Ibsen
>Priority: Major
> Fix For: 2.23.0
>
>
> If you have complex types like javax.sql.DataSource and wants to allow to
> configure this via spring boot autoconfiguration in application.properties -
> then the generated spring boot classes with all the options will use
> getter/setter of types javax.sql.DataSource. That seems correct, but the
> spring-boot tooling itself (that generates additional json file) will skip
> those as it only support primitives and string types.
> So we may need to fool, and generate the getter/setter as String type as you
> use it for configuring it as a bean reference by id anyway, eg
> camel.component.jdbc.data-source = #myDataSource
> We can add in the javadoc that the type is javax.sql.DataSource.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CAMEL-12646) camel-spring-boot - Auto configuration of complex types should be more tooling friendly
[
https://issues.apache.org/jira/browse/CAMEL-12646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16541569#comment-16541569
]
Claus Ibsen commented on CAMEL-12646:
-
This is the generated source code snippet
{code:java}
@Generated("org.apache.camel.maven.packaging.SpringBootAutoConfigurationMojo")
@ConfigurationProperties(prefix = "camel.component.jdbc")
public class JdbcComponentConfiguration
extends
ComponentConfigurationPropertiesCommon {
/**
* To use the DataSource instance instead of looking up the data source by
* name from the registry.
*/
private DataSource dataSource;
/**
* Whether the component should resolve property placeholders on itself when
* starting. Only properties which are of String type can use property
* placeholders.
*/
private Boolean resolvePropertyPlaceholders = true;
{code}
> camel-spring-boot - Auto configuration of complex types should be more
> tooling friendly
> ---
>
> Key: CAMEL-12646
> URL: https://issues.apache.org/jira/browse/CAMEL-12646
> Project: Camel
> Issue Type: Improvement
> Components: camel-spring-boot-starters, tooling
>Reporter: Claus Ibsen
>Assignee: Claus Ibsen
>Priority: Major
> Fix For: 2.23.0
>
>
> If you have complex types like javax.sql.DataSource and wants to allow to
> configure this via spring boot autoconfiguration in application.properties -
> then the generated spring boot classes with all the options will use
> getter/setter of types javax.sql.DataSource. That seems correct, but the
> spring-boot tooling itself (that generates additional json file) will skip
> those as it only support primitives and string types.
> So we may need to fool, and generate the getter/setter as String type as you
> use it for configuring it as a bean reference by id anyway, eg
> camel.component.jdbc.data-source = #myDataSource
> We can add in the javadoc that the type is javax.sql.DataSource.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CAMEL-12646) camel-spring-boot - Auto configuration of complex types should be more tooling friendly
Claus Ibsen created CAMEL-12646: --- Summary: camel-spring-boot - Auto configuration of complex types should be more tooling friendly Key: CAMEL-12646 URL: https://issues.apache.org/jira/browse/CAMEL-12646 Project: Camel Issue Type: Improvement Components: camel-spring-boot-starters, tooling Reporter: Claus Ibsen Assignee: Claus Ibsen Fix For: 2.23.0 If you have complex types like javax.sql.DataSource and wants to allow to configure this via spring boot autoconfiguration in application.properties - then the generated spring boot classes with all the options will use getter/setter of types javax.sql.DataSource. That seems correct, but the spring-boot tooling itself (that generates additional json file) will skip those as it only support primitives and string types. So we may need to fool, and generate the getter/setter as String type as you use it for configuring it as a bean reference by id anyway, eg camel.component.jdbc.data-source = #myDataSource We can add in the javadoc that the type is javax.sql.DataSource. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (CAMEL-12638) DefaultFluentProducerTemplate is not thread safe
[
https://issues.apache.org/jira/browse/CAMEL-12638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16541562#comment-16541562
]
Lukasz edited comment on CAMEL-12638 at 7/12/18 12:40 PM:
--
I'm not really convinced by that [~njiang]. Even in the _Camel in Action
(Second Edition)_ book, Claus and Jonathan use it a standard bean that can be
called to execute a service not a builder (see _Listing 7.12 JAX-RS_
_REST implementation_)_:_
{code:java}
@ApplicationScoped
@Path ( "/api" )
public class RulesController {
@Inject
@Uri ( "direct:inventory" )
private FluentProducerTemplate producer;
@GET
@Produces ( MediaType.APPLICATION_JSON )
@Path ( "/rules/{cartIds}" )
public List rules( @PathParam ( "cartIds" ) String cartIds ) {
List answer = new ArrayList<>();
ItemsDto inventory = producer.request( ItemsDto.class );
[...]
}
}{code}
Obviously they don't refer to a specific implementation but we can all imagine
which implementation is provided by default. Also if it was supposed to be
*just* a builder I find it misleading that the class actually implements a
_Service_ interface.
was (Author: lucas_):
I'm not really convinced by that [~njiang]. Even in the _Camel in Action
(Second Edition)_ **book, Claus and Jonathan use it a standard bean that can be
called to execute a service not a builder (see _Listing 7.12 JAX-RS_
_REST implementation_)_:_
{code:java}
@ApplicationScoped
@Path ( "/api" )
public class RulesController {
@Inject
@Uri ( "direct:inventory" )
private FluentProducerTemplate producer;
@GET
@Produces ( MediaType.APPLICATION_JSON )
@Path ( "/rules/{cartIds}" )
public List rules( @PathParam ( "cartIds" ) String cartIds ) {
List answer = new ArrayList<>();
ItemsDto inventory = producer.request( ItemsDto.class );
[...]
}
}{code}
Obviously they don't refer to a specific implementation but we can all imagine
which implementation is provided by default. Also if it was supposed to be
*just* a builder I find it misleading that the class actually implements a
_Service_ interface.
> DefaultFluentProducerTemplate is not thread safe
>
>
> Key: CAMEL-12638
> URL: https://issues.apache.org/jira/browse/CAMEL-12638
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 2.20.2
>Reporter: Lukasz
>Priority: Major
>
> I think we have rediscovered the CAMEL-10820 bug. A body of one request gets
> replaced with a body of proceeding request, in our case we use *request()*
> method instead of *asyncSend()*.
> We use camel together with spring-boot. Consider following code:
>
> {code:java}
> @Service
> public class UseCamelService {
>private FluentProducerTemplate producer;
>@Autowired
>public UseCamelService(FluentProducerTemplate producer) {
> this.producer = producer;
>}
>public String getValueFromCamel(String body) {
> return producer.to("route").withBody(body).request(String.class);
>}
> }
> {code}
> If *UseCamelService.getValueFromCamel()* gets called from two different
> threads it is possible for the latter one to override the body of the first
> one.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (CAMEL-12638) DefaultFluentProducerTemplate is not thread safe
[
https://issues.apache.org/jira/browse/CAMEL-12638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16541562#comment-16541562
]
Lukasz edited comment on CAMEL-12638 at 7/12/18 12:39 PM:
--
I'm not really convinced by that [~njiang]. Even in the _Camel in Action
(Second Edition)_ **book, Claus and Jonathan use it a standard bean that can be
called to execute a service not a builder (see _Listing 7.12 JAX-RS_
_REST implementation_)_:_
{code:java}
@ApplicationScoped
@Path ( "/api" )
public class RulesController {
@Inject
@Uri ( "direct:inventory" )
private FluentProducerTemplate producer;
@GET
@Produces ( MediaType.APPLICATION_JSON )
@Path ( "/rules/{cartIds}" )
public List rules( @PathParam ( "cartIds" ) String cartIds ) {
List answer = new ArrayList<>();
ItemsDto inventory = producer.request( ItemsDto.class );
[...]
}
}{code}
Obviously they don't refer to a specific implementation but we can all imagine
which implementation is provided by default. Also if it was supposed to be
*just* a builder I find it misleading that the class actually implements a
_Service_ interface.
was (Author: lucas_):
I'm not really convinced by that [~njiang]. Even in the _Camel in Action
(Second Edition)_ **book, Claus and Jonathan use it a standard bean that can be
called to execute a service not a builder (see _Listing 7.12 JAX-RS_
_REST implementation_)_:_
_@ApplicationScoped
@Path("/api")
public class RulesController \{
@Inject
@Uri ( "direct:inventory" )
private FluentProducerTemplate producer;
@GET
@Produces ( MediaType.APPLICATION_JSON )
@Path ( "/rules/{cartIds}" )
public List rules( @PathParam ( "cartIds" ) String cartIds ) \{
List answer = new ArrayList<>();
ItemsDto inventory = producer.request( ItemsDto.class );
[...]
}
}_
Obviously they don't refer to a specific implementation but we can all imagine
which implementation is provided by default. Also if it was supposed to be
*just* a builder I find it misleading that the class actually implements a
_Service_ interface.
> DefaultFluentProducerTemplate is not thread safe
>
>
> Key: CAMEL-12638
> URL: https://issues.apache.org/jira/browse/CAMEL-12638
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 2.20.2
>Reporter: Lukasz
>Priority: Major
>
> I think we have rediscovered the CAMEL-10820 bug. A body of one request gets
> replaced with a body of proceeding request, in our case we use *request()*
> method instead of *asyncSend()*.
> We use camel together with spring-boot. Consider following code:
>
> {code:java}
> @Service
> public class UseCamelService {
>private FluentProducerTemplate producer;
>@Autowired
>public UseCamelService(FluentProducerTemplate producer) {
> this.producer = producer;
>}
>public String getValueFromCamel(String body) {
> return producer.to("route").withBody(body).request(String.class);
>}
> }
> {code}
> If *UseCamelService.getValueFromCamel()* gets called from two different
> threads it is possible for the latter one to override the body of the first
> one.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CAMEL-12638) DefaultFluentProducerTemplate is not thread safe
[
https://issues.apache.org/jira/browse/CAMEL-12638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16541562#comment-16541562
]
Lukasz commented on CAMEL-12638:
I'm not really convinced by that [~njiang]. Even in the _Camel in Action
(Second Edition)_ **book, Claus and Jonathan use it a standard bean that can be
called to execute a service not a builder (see _Listing 7.12 JAX-RS_
_REST implementation_)_:_
_@ApplicationScoped
@Path("/api")
public class RulesController \{
@Inject
@Uri ( "direct:inventory" )
private FluentProducerTemplate producer;
@GET
@Produces ( MediaType.APPLICATION_JSON )
@Path ( "/rules/{cartIds}" )
public List rules( @PathParam ( "cartIds" ) String cartIds ) \{
List answer = new ArrayList<>();
ItemsDto inventory = producer.request( ItemsDto.class );
[...]
}
}_
Obviously they don't refer to a specific implementation but we can all imagine
which implementation is provided by default. Also if it was supposed to be
*just* a builder I find it misleading that the class actually implements a
_Service_ interface.
> DefaultFluentProducerTemplate is not thread safe
>
>
> Key: CAMEL-12638
> URL: https://issues.apache.org/jira/browse/CAMEL-12638
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 2.20.2
>Reporter: Lukasz
>Priority: Major
>
> I think we have rediscovered the CAMEL-10820 bug. A body of one request gets
> replaced with a body of proceeding request, in our case we use *request()*
> method instead of *asyncSend()*.
> We use camel together with spring-boot. Consider following code:
>
> {code:java}
> @Service
> public class UseCamelService {
>private FluentProducerTemplate producer;
>@Autowired
>public UseCamelService(FluentProducerTemplate producer) {
> this.producer = producer;
>}
>public String getValueFromCamel(String body) {
> return producer.to("route").withBody(body).request(String.class);
>}
> }
> {code}
> If *UseCamelService.getValueFromCamel()* gets called from two different
> threads it is possible for the latter one to override the body of the first
> one.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CAMEL-12639) tooling - Provide line numbers for validation result for java dsl
[ https://issues.apache.org/jira/browse/CAMEL-12639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16541524#comment-16541524 ] Claus Ibsen commented on CAMEL-12639: - Do you have a sample project or something that reproduces this, as the line number is set if its possible to know it. > tooling - Provide line numbers for validation result for java dsl > - > > Key: CAMEL-12639 > URL: https://issues.apache.org/jira/browse/CAMEL-12639 > Project: Camel > Issue Type: Improvement > Components: tooling >Affects Versions: 2.22.0 >Reporter: Aurélien Pupier >Priority: Major > Fix For: 2.23.0 > > Attachments: screenshot-1.png > > > currently it is provided for xml dsl but not for java dsl -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CAMEL-12640) tooling - Provide character position in validation result
[ https://issues.apache.org/jira/browse/CAMEL-12640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-12640: Priority: Minor (was: Major) > tooling - Provide character position in validation result > - > > Key: CAMEL-12640 > URL: https://issues.apache.org/jira/browse/CAMEL-12640 > Project: Camel > Issue Type: Improvement > Components: tooling >Affects Versions: 2.22.0 >Reporter: Aurélien Pupier >Priority: Minor > > currently the line start and line end are provided but not the character > position -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CAMEL-12639) tooling - Provide line numbers for validation result for java dsl
[ https://issues.apache.org/jira/browse/CAMEL-12639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-12639: Priority: Minor (was: Major) > tooling - Provide line numbers for validation result for java dsl > - > > Key: CAMEL-12639 > URL: https://issues.apache.org/jira/browse/CAMEL-12639 > Project: Camel > Issue Type: Improvement > Components: tooling >Affects Versions: 2.22.0 >Reporter: Aurélien Pupier >Priority: Minor > Fix For: 2.23.0 > > Attachments: screenshot-1.png > > > currently it is provided for xml dsl but not for java dsl -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CAMEL-12638) DefaultFluentProducerTemplate is not thread safe
[
https://issues.apache.org/jira/browse/CAMEL-12638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16541360#comment-16541360
]
Willem Jiang commented on CAMEL-12638:
--
The FluentProducerTemplate works as the Builder class with the fluent API to
setup the internal states which is not thread safe. You may need to use the
DefaultProducerTemplate to do the job.
> DefaultFluentProducerTemplate is not thread safe
>
>
> Key: CAMEL-12638
> URL: https://issues.apache.org/jira/browse/CAMEL-12638
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 2.20.2
>Reporter: Lukasz
>Priority: Major
>
> I think we have rediscovered the CAMEL-10820 bug. A body of one request gets
> replaced with a body of proceeding request, in our case we use *request()*
> method instead of *asyncSend()*.
> We use camel together with spring-boot. Consider following code:
>
> {code:java}
> @Service
> public class UseCamelService {
>private FluentProducerTemplate producer;
>@Autowired
>public UseCamelService(FluentProducerTemplate producer) {
> this.producer = producer;
>}
>public String getValueFromCamel(String body) {
> return producer.to("route").withBody(body).request(String.class);
>}
> }
> {code}
> If *UseCamelService.getValueFromCamel()* gets called from two different
> threads it is possible for the latter one to override the body of the first
> one.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CAMEL-12549) Upgrade to Groovy 2.5
[ https://issues.apache.org/jira/browse/CAMEL-12549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16541303#comment-16541303 ] Önder Sezgin commented on CAMEL-12549: -- jar is absent in public repos. this could be tried to update after repos are in sync > Upgrade to Groovy 2.5 > - > > Key: CAMEL-12549 > URL: https://issues.apache.org/jira/browse/CAMEL-12549 > Project: Camel > Issue Type: Task > Components: camel-groovy >Reporter: Claus Ibsen >Priority: Minor > Fix For: 2.23.0 > > > Groovy 2.5 was just released. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CAMEL-12645) camel-jdbc - Allow to use default datasource from spring-boot
[ https://issues.apache.org/jira/browse/CAMEL-12645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-12645. - Resolution: Fixed Assignee: Claus Ibsen You can now use the name dataSource or default as DS name in the endpoint uri and Camel will discover it from the registry / SB. > camel-jdbc - Allow to use default datasource from spring-boot > - > > Key: CAMEL-12645 > URL: https://issues.apache.org/jira/browse/CAMEL-12645 > Project: Camel > Issue Type: Improvement > Components: camel-jdbc >Reporter: Claus Ibsen >Assignee: Claus Ibsen >Priority: Major > Fix For: 2.23.0 > > > Like we do in camel-sql where we lookup and use default data source if there > is none configured and there is only 1. Then camel-sql and camel-jdbc is a > bit similar and easier to use, such as when using spring boot. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CAMEL-12645) camel-jdbc - Allow to use default datasource from spring-boot
Claus Ibsen created CAMEL-12645: --- Summary: camel-jdbc - Allow to use default datasource from spring-boot Key: CAMEL-12645 URL: https://issues.apache.org/jira/browse/CAMEL-12645 Project: Camel Issue Type: Improvement Components: camel-jdbc Reporter: Claus Ibsen Fix For: 2.23.0 Like we do in camel-sql where we lookup and use default data source if there is none configured and there is only 1. Then camel-sql and camel-jdbc is a bit similar and easier to use, such as when using spring boot. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CAMEL-12641) Aws-sns and aws-sqs components not accepting Date type message attributes
[
https://issues.apache.org/jira/browse/CAMEL-12641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16541262#comment-16541262
]
ASF GitHub Bot commented on CAMEL-12641:
saravanakumar1987 commented on issue #2421: CAMEL-12641 : Aws-sns and aws-sqs
components not accepting Date type …
URL: https://github.com/apache/camel/pull/2421#issuecomment-404419941
@davsclaus
The date format can be customized to any particular standard by updating the
header value before calling camel aws endpoint. And default format can be the
one returned by
https://docs.oracle.com/javase/8/docs/api/java/util/Date.html#toString--
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Aws-sns and aws-sqs components not accepting Date type message attributes
> -
>
> Key: CAMEL-12641
> URL: https://issues.apache.org/jira/browse/CAMEL-12641
> Project: Camel
> Issue Type: Improvement
> Components: camel-aws
>Affects Versions: 2.21.1
>Reporter: Saravanakumar Selvaraj
>Assignee: Andrea Cosentino
>Priority: Minor
> Fix For: 2.23.0
>
>
> Camel aws-sns and aws-sqs components not accepting Date type message
> attributes. For example, the camel route like,
> {{ }}
> {{
[jira] [Updated] (CAMEL-12639) tooling - Provide line numbers for validation result for java dsl
[ https://issues.apache.org/jira/browse/CAMEL-12639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-12639: Summary: tooling - Provide line numbers for validation result for java dsl (was: Provide line numbers for validation result for java dsl) > tooling - Provide line numbers for validation result for java dsl > - > > Key: CAMEL-12639 > URL: https://issues.apache.org/jira/browse/CAMEL-12639 > Project: Camel > Issue Type: Improvement > Components: tooling >Affects Versions: 2.22.0 >Reporter: Aurélien Pupier >Priority: Major > Fix For: 2.23.0 > > Attachments: screenshot-1.png > > > currently it is provided for xml dsl but not for java dsl -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CAMEL-12640) tooling - Provide character position in validation result
[ https://issues.apache.org/jira/browse/CAMEL-12640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-12640: Summary: tooling - Provide character position in validation result (was: Provide character position in validation result) > tooling - Provide character position in validation result > - > > Key: CAMEL-12640 > URL: https://issues.apache.org/jira/browse/CAMEL-12640 > Project: Camel > Issue Type: Improvement > Components: tooling >Affects Versions: 2.22.0 >Reporter: Aurélien Pupier >Priority: Major > > currently the line start and line end are provided but not the character > position -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CAMEL-12643) camel-rabbitmq - Inadequate information for handling catch clauses
[
https://issues.apache.org/jira/browse/CAMEL-12643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-12643:
Summary: camel-rabbitmq - Inadequate information for handling catch clauses
(was: Inadequate information for handling catch clauses)
> camel-rabbitmq - Inadequate information for handling catch clauses
> --
>
> Key: CAMEL-12643
> URL: https://issues.apache.org/jira/browse/CAMEL-12643
> Project: Camel
> Issue Type: Improvement
> Components: camel-rabbitmq
>Reporter: Zhenhao Li
>Priority: Minor
>
> There are some situations that different exception types are caught, but the
> handling of those exceptions cannot show the differences between those types.
> Here are the code snippets which have this problem:
> org.apache.camel.component.rabbitmq.*RabbitConsumer*.handleShutdownSignal,
> *Line 271*
> catch (IOException | TimeoutException e)
> { log.warn("Unable to obtain a RabbitMQ channel. Will try again"); ...
> }
> It may cause confusions to the person who is reading the log, the person can
> not know what exception happened here and cannot distinguish if the exception
> type is IOException or TimeoutException. Simply adding a full stack trace is
> able to improve it.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (CAMEL-12633) camel-jmx - Add support for monitoring boolean attribute changes
[ https://issues.apache.org/jira/browse/CAMEL-12633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen resolved CAMEL-12633. - Resolution: Fixed The regular consumer can now observe attributes and use the string to compare with match/differ so you can trigger only when needed. For example to observe when a boolean attribute changes to true or false etc. The regular string monitor cannot do that. > camel-jmx - Add support for monitoring boolean attribute changes > > > Key: CAMEL-12633 > URL: https://issues.apache.org/jira/browse/CAMEL-12633 > Project: Camel > Issue Type: Improvement > Components: camel-jmx >Reporter: Claus Ibsen >Assignee: Claus Ibsen >Priority: Minor > Fix For: 2.23.0 > > > We can monitor counters, gauges and string values. But its not possible to > monitor when a boolean value changes. > You cannot use the string monitor as JMX does not support that :( > So we need to add out own code to handle booleans -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CAMEL-12643) Inadequate information for handling catch clauses
[
https://issues.apache.org/jira/browse/CAMEL-12643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-12643:
Component/s: camel-rabbitmq
> Inadequate information for handling catch clauses
> -
>
> Key: CAMEL-12643
> URL: https://issues.apache.org/jira/browse/CAMEL-12643
> Project: Camel
> Issue Type: Improvement
> Components: camel-rabbitmq
>Reporter: Zhenhao Li
>Priority: Minor
>
> There are some situations that different exception types are caught, but the
> handling of those exceptions cannot show the differences between those types.
> Here are the code snippets which have this problem:
> org.apache.camel.component.rabbitmq.*RabbitConsumer*.handleShutdownSignal,
> *Line 271*
> catch (IOException | TimeoutException e)
> { log.warn("Unable to obtain a RabbitMQ channel. Will try again"); ...
> }
> It may cause confusions to the person who is reading the log, the person can
> not know what exception happened here and cannot distinguish if the exception
> type is IOException or TimeoutException. Simply adding a full stack trace is
> able to improve it.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CAMEL-12644) Generate documentation for Spring Boot starters
Zoran Regvart created CAMEL-12644: - Summary: Generate documentation for Spring Boot starters Key: CAMEL-12644 URL: https://issues.apache.org/jira/browse/CAMEL-12644 Project: Camel Issue Type: New Feature Components: camel-spring-boot-starters Reporter: Zoran Regvart We could add auto-configuration properties section to the component documentation something like that can be seen in the [spring-boot documentation|https://docs.spring.io/spring-boot/docs/1.5.14.RELEASE/reference/htmlsingle/#common-application-properties] to help the users know which properties are available in application.[properties|yaml] under what keys. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CAMEL-12638) DefaultFluentProducerTemplate is not thread safe
[
https://issues.apache.org/jira/browse/CAMEL-12638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16541252#comment-16541252
]
Lukasz commented on CAMEL-12638:
I came up with the same conclusion as you [~neildrummonddorado]. There is no
mention about this in the _DefaultFluentProducerTemplate_ javadoc, but the one
for _FluentProducerTemplate_ clearly states that the producer is threadsafe and
I would kind of expect that the same should apply for its implementations.
> DefaultFluentProducerTemplate is not thread safe
>
>
> Key: CAMEL-12638
> URL: https://issues.apache.org/jira/browse/CAMEL-12638
> Project: Camel
> Issue Type: Bug
> Components: camel-core
>Affects Versions: 2.20.2
>Reporter: Lukasz
>Priority: Major
>
> I think we have rediscovered the CAMEL-10820 bug. A body of one request gets
> replaced with a body of proceeding request, in our case we use *request()*
> method instead of *asyncSend()*.
> We use camel together with spring-boot. Consider following code:
>
> {code:java}
> @Service
> public class UseCamelService {
>private FluentProducerTemplate producer;
>@Autowired
>public UseCamelService(FluentProducerTemplate producer) {
> this.producer = producer;
>}
>public String getValueFromCamel(String body) {
> return producer.to("route").withBody(body).request(String.class);
>}
> }
> {code}
> If *UseCamelService.getValueFromCamel()* gets called from two different
> threads it is possible for the latter one to override the body of the first
> one.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (CAMEL-12515) the camel splitter loses attachments
[ https://issues.apache.org/jira/browse/CAMEL-12515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16541250#comment-16541250 ] Önder Sezgin edited comment on CAMEL-12515 at 7/12/18 7:21 AM: --- [~ronny.aerts.intris], why dont you split body and try tosplit attachments? could please you give an example? was (Author: onders): [~ronny.aerts.intris], why dont you split body or split attachments? could please you give an example? > the camel splitter loses attachments > > > Key: CAMEL-12515 > URL: https://issues.apache.org/jira/browse/CAMEL-12515 > Project: Camel > Issue Type: Improvement > Components: camel-core-xml >Affects Versions: 2.20.3 > Environment: I use camel 2.20.3 in xml not java. >Reporter: Ronny Aerts >Priority: Minor > > * I have a process which uses at lot of attachments (coming in from a mail) > and I have to filter on several of them. > * I created a javascript to loop over the attachments and use the attachment > id in combination with a regex to determine if the attachment is applicable. > Several of these attachments can be applicable. I keep an ArrayList of > applicable attachments which I put in the body. > * I split on the (arraylist) body to handle the individual attachments one > by one but this doesn't work because there are no attachments anymore inside > the split. > * It would be very helpful to me if I could use the attachments inside the > split. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CAMEL-12515) the camel splitter loses attachments
[ https://issues.apache.org/jira/browse/CAMEL-12515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16541250#comment-16541250 ] Önder Sezgin commented on CAMEL-12515: -- [~ronny.aerts.intris], why dont you split body or split attachments? could please you give an example? > the camel splitter loses attachments > > > Key: CAMEL-12515 > URL: https://issues.apache.org/jira/browse/CAMEL-12515 > Project: Camel > Issue Type: Improvement > Components: camel-core-xml >Affects Versions: 2.20.3 > Environment: I use camel 2.20.3 in xml not java. >Reporter: Ronny Aerts >Priority: Minor > > * I have a process which uses at lot of attachments (coming in from a mail) > and I have to filter on several of them. > * I created a javascript to loop over the attachments and use the attachment > id in combination with a regex to determine if the attachment is applicable. > Several of these attachments can be applicable. I keep an ArrayList of > applicable attachments which I put in the body. > * I split on the (arraylist) body to handle the individual attachments one > by one but this doesn't work because there are no attachments anymore inside > the split. > * It would be very helpful to me if I could use the attachments inside the > split. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
