[jira] [Commented] (CAMEL-7848) Netty-Http component: add support for registry's encoders and decoders
[ https://issues.apache.org/jira/browse/CAMEL-7848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14182480#comment-14182480 ] Willem Jiang commented on CAMEL-7848: - Hi Yaron, Thanks for reporting the issue. It's my bad, if we want to decompress the http message , we need to put the handler after the HttpClientCodec. I will updated the code with a test to setup the encoders and decoders rightly. Regards, Willem Netty-Http component: add support for registry's encoders and decoders -- Key: CAMEL-7848 URL: https://issues.apache.org/jira/browse/CAMEL-7848 Project: Camel Issue Type: New Feature Components: camel-netty-http Affects Versions: 2.14.0 Reporter: Yaron A Assignee: Willem Jiang Fix For: 2.14.1, 2.15.0 Currently the camel-netty component supports setting encoders decoders that enlisted in the registry. It will be very helpful to have this functionality similarly supported in the camel-netty-http component too. From what I saw, camel-netty's ClientPipelineFactory implementation (DefaultClientPipelineFactory) supports it in the getPipeline method but a similar implementation does not exist in camel-netty-http's ClientPipelineFactory implementation (HttpClientPipelineFactory). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-7946) Backward compatibility of RoutingSlip/RecipientList statement is violated
[ https://issues.apache.org/jira/browse/CAMEL-7946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomas Hanus updated CAMEL-7946: --- Description: Currently we fixed issue in production of route that uses routingSlip statement for dynamic resolution of endpoint. This route is synchronous when next endpoint expects some result from previous endpoint that was resolved by routingSlip. Problem is, and we don't know how long (camel version), that without explicit statement which defines ExchangePattern as *InOut* before using routingSlip unexpected behaviour occurs. It looks like *InOnly* by default. *wrong approach*: .recipientList(method(MyRoute.class, getUri)).id(ENDPOINT_ID_EXT); *correct behaviour*: // for request/reply .setExchangePattern(ExchangePattern.InOut) .recipientList(method(MyRoute.class, getUri)).id(ENDPOINT_ID_EXT); Because this change is *not backwards compatible* and has a very unexpected behavior and this issue is difficult to identify. was: Currently we fixed issue in production of route that uses routingSlip statement for dynamic resolution of endpoint. This route is synchronous when next endpoint expects some result from previous endpoint that was resolved by routingSlip. Problem is, and we don't know how long (camel version), that without explicit statement which defines ExchangePattern as *InOut* before using routingSlip unexpected behaviour occurs. *wrong approach*: .recipientList(method(MyRoute.class, getUri)).id(ENDPOINT_ID_EXT); *correct behaviour*: // for request/reply .setExchangePattern(ExchangePattern.InOut) .recipientList(method(MyRoute.class, getUri)).id(ENDPOINT_ID_EXT); Because this change is *not backwards compatible* and has a very unexpected behavior and this issue is difficult to identify. Backward compatibility of RoutingSlip/RecipientList statement is violated - Key: CAMEL-7946 URL: https://issues.apache.org/jira/browse/CAMEL-7946 Project: Camel Issue Type: Bug Affects Versions: 2.13.2 Reporter: Tomas Hanus Labels: core Currently we fixed issue in production of route that uses routingSlip statement for dynamic resolution of endpoint. This route is synchronous when next endpoint expects some result from previous endpoint that was resolved by routingSlip. Problem is, and we don't know how long (camel version), that without explicit statement which defines ExchangePattern as *InOut* before using routingSlip unexpected behaviour occurs. It looks like *InOnly* by default. *wrong approach*: .recipientList(method(MyRoute.class, getUri)).id(ENDPOINT_ID_EXT); *correct behaviour*: // for request/reply .setExchangePattern(ExchangePattern.InOut) .recipientList(method(MyRoute.class, getUri)).id(ENDPOINT_ID_EXT); Because this change is *not backwards compatible* and has a very unexpected behavior and this issue is difficult to identify. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-7848) Netty-Http component: add support for registry's encoders and decoders
[ https://issues.apache.org/jira/browse/CAMEL-7848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Willem Jiang resolved CAMEL-7848. - Resolution: Fixed Netty-Http component: add support for registry's encoders and decoders -- Key: CAMEL-7848 URL: https://issues.apache.org/jira/browse/CAMEL-7848 Project: Camel Issue Type: New Feature Components: camel-netty-http Affects Versions: 2.14.0 Reporter: Yaron A Assignee: Willem Jiang Fix For: 2.14.1, 2.15.0 Currently the camel-netty component supports setting encoders decoders that enlisted in the registry. It will be very helpful to have this functionality similarly supported in the camel-netty-http component too. From what I saw, camel-netty's ClientPipelineFactory implementation (DefaultClientPipelineFactory) supports it in the getPipeline method but a similar implementation does not exist in camel-netty-http's ClientPipelineFactory implementation (HttpClientPipelineFactory). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-7952) Camel REST does not handle same path with differents VERBS
[
https://issues.apache.org/jira/browse/CAMEL-7952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Willem Jiang resolved CAMEL-7952.
-
Resolution: Duplicate
Fix Version/s: 2.15.0
2.14.1
Assignee: Willem Jiang
Please try to use the latest Camel 2.14.1-SNAPSHOT which already has the fix
patch.
Camel REST does not handle same path with differents VERBS
--
Key: CAMEL-7952
URL: https://issues.apache.org/jira/browse/CAMEL-7952
Project: Camel
Issue Type: Bug
Components: camel-core
Affects Versions: 2.14.0
Environment: ALL
Reporter: Pierre-Alban DEWITTE
Assignee: Willem Jiang
Fix For: 2.14.1, 2.15.0
If we had the same path with different verbs (GET, POST, DELETE) only one is
randomly choosen.
To reproduce this issue i just changed the route builder in
camel-example-servlet-rest-tomcat.
In UserRouteBuilder.java change the last statement of configure() method
with :
rest(/user).description(User rest service)
.consumes(application/json).produces(application/json)
.get(/name).description(GET).outTypeList(User.class)
.to(bean:userService?method=listUsers)
.post(/name).description(POST).to(bean:userService?method=listUsers)
.delete(/{name}).description(DELETE).to(bean:userService?method=listUsers)
;
After a quick debug it seams that the CamelServlet is fiiling a map of
HttpConsumer. The key is path so only last one can be used further.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-7946) Backward compatibility of RoutingSlip/RecipientList statement is violated
[ https://issues.apache.org/jira/browse/CAMEL-7946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14182528#comment-14182528 ] Willem Jiang commented on CAMEL-7946: - It's always a good practise to specify the Exchange pattern explicitly in your case, as camel is trying its best to look up the message from the exchange[1]. If you didn't specify the Exchange pattern in the route, the exchange pattern could be decided by the exchange which you send to the camel route or the from endpoint. [1]http://camel.apache.org/using-getin-or-getout-methods-on-exchange.html Backward compatibility of RoutingSlip/RecipientList statement is violated - Key: CAMEL-7946 URL: https://issues.apache.org/jira/browse/CAMEL-7946 Project: Camel Issue Type: Bug Affects Versions: 2.13.2 Reporter: Tomas Hanus Labels: core Currently we fixed issue in production of route that uses routingSlip statement for dynamic resolution of endpoint. This route is synchronous when next endpoint expects some result from previous endpoint that was resolved by routingSlip. Problem is, and we don't know how long (camel version), that without explicit statement which defines ExchangePattern as *InOut* before using routingSlip unexpected behaviour occurs. It looks like *InOnly* by default. *wrong approach*: .recipientList(method(MyRoute.class, getUri)).id(ENDPOINT_ID_EXT); *correct behaviour*: // for request/reply .setExchangePattern(ExchangePattern.InOut) .recipientList(method(MyRoute.class, getUri)).id(ENDPOINT_ID_EXT); Because this change is *not backwards compatible* and has a very unexpected behavior and this issue is difficult to identify. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-7948) Add support for more/new encryption/signature algorithms
[
https://issues.apache.org/jira/browse/CAMEL-7948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14182565#comment-14182565
]
Willem Jiang commented on CAMEL-7948:
-
Hi Colm,
I tried to run the tests after applied the patch.
Now I got below test errors. Could you double check it ?
{code}
Failed tests:
EncryptionAlgorithmTest.testCAMELLIA_192:303 mock://encrypted Received
message count. Expected: 1 but was: 0
EncryptionAlgorithmTest.testCAMELLIA_256:327 mock://encrypted Received
message count. Expected: 1 but was: 0
EncryptionAlgorithmTest.testAES192_GCM:158 mock://encrypted Received message
count. Expected: 1 but was: 0
EncryptionAlgorithmTest.testAES256_GCM:207 mock://encrypted Received message
count. Expected: 1 but was: 0
EncryptionAlgorithmTest.testAES192:134 mock://encrypted Received message
count. Expected: 1 but was: 0
EncryptionAlgorithmTest.testAES256:183 mock://encrypted Received message
count. Expected: 1 but was: 0
{code}
Add support for more/new encryption/signature algorithms
Key: CAMEL-7948
URL: https://issues.apache.org/jira/browse/CAMEL-7948
Project: Camel
Issue Type: Improvement
Components: camel-xmlsecurity
Reporter: Colm O hEigeartaigh
Assignee: Willem Jiang
Priority: Minor
Attachments: camel-7948.patch
See attached for a patch to support some new (to XML Security) digest
algorithms such as RIPE-MD160 and SEED + CAMELLIA encryption algorithms. Also
added a fairly comprehensive set of tests for different encryption/signature
algorithms.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (CAMEL-6406) Add support to ObjectHelper.getException() for Java 1.7 Throwable.getSuppressed()
[ https://issues.apache.org/jira/browse/CAMEL-6406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Willem Jiang reassigned CAMEL-6406: --- Assignee: Willem Jiang Add support to ObjectHelper.getException() for Java 1.7 Throwable.getSuppressed() - Key: CAMEL-6406 URL: https://issues.apache.org/jira/browse/CAMEL-6406 Project: Camel Issue Type: Improvement Components: camel-core Affects Versions: 2.11.0, 2.14.0 Reporter: Aaron Whiteside Assignee: Willem Jiang Add support to ObjectHelper.getException() for Java 1.7 Throwable.getSuppressed() Now that exceptions can be suppressed in Java 1.7 Camel should be able to detect when running in a 1.7 JVM and use the additional suppressed Throwables when searching for specific exception types. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-6406) Add support to ObjectHelper.getException() for Java 1.7 Throwable.getSuppressed()
[
https://issues.apache.org/jira/browse/CAMEL-6406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14182610#comment-14182610
]
Willem Jiang commented on CAMEL-6406:
-
I just wrote a simple test , the ex.getSuppressed() just return a empty array,
we can not use it in the ObjectHelper.
{code}
Exception cause0 = new IllegalArgumentException(test0);
Exception cause1 = new RuntimeCamelException(test1, cause0);
Throwable ex = new Throwable(Test message, cause1);
System.out.println(cause1.getSuppressed().length);
for (Throwable t : ex.getSuppressed()) {
System.out.println(t);
}
{code}
Add support to ObjectHelper.getException() for Java 1.7
Throwable.getSuppressed()
-
Key: CAMEL-6406
URL: https://issues.apache.org/jira/browse/CAMEL-6406
Project: Camel
Issue Type: Improvement
Components: camel-core
Affects Versions: 2.11.0, 2.14.0
Reporter: Aaron Whiteside
Assignee: Willem Jiang
Add support to ObjectHelper.getException() for Java 1.7
Throwable.getSuppressed()
Now that exceptions can be suppressed in Java 1.7 Camel should be able to
detect when running in a 1.7 JVM and use the additional suppressed Throwables
when searching for specific exception types.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-7946) Backward compatibility of RoutingSlip/RecipientList statement is violated
[ https://issues.apache.org/jira/browse/CAMEL-7946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14182624#comment-14182624 ] Tomas Hanus commented on CAMEL-7946: Yes, I understand and agree, but problem is that this behaviour was changed because without some changes in this route was everything ok with previous camel version (2.11.1), but after upgrade of camel version this issue occurs. Backward compatibility of RoutingSlip/RecipientList statement is violated - Key: CAMEL-7946 URL: https://issues.apache.org/jira/browse/CAMEL-7946 Project: Camel Issue Type: Bug Affects Versions: 2.13.2 Reporter: Tomas Hanus Labels: core Currently we fixed issue in production of route that uses routingSlip statement for dynamic resolution of endpoint. This route is synchronous when next endpoint expects some result from previous endpoint that was resolved by routingSlip. Problem is, and we don't know how long (camel version), that without explicit statement which defines ExchangePattern as *InOut* before using routingSlip unexpected behaviour occurs. It looks like *InOnly* by default. *wrong approach*: .recipientList(method(MyRoute.class, getUri)).id(ENDPOINT_ID_EXT); *correct behaviour*: // for request/reply .setExchangePattern(ExchangePattern.InOut) .recipientList(method(MyRoute.class, getUri)).id(ENDPOINT_ID_EXT); Because this change is *not backwards compatible* and has a very unexpected behavior and this issue is difficult to identify. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-7948) Add support for more/new encryption/signature algorithms
[ https://issues.apache.org/jira/browse/CAMEL-7948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Colm O hEigeartaigh updated CAMEL-7948: --- Attachment: camel-7498-revised.patch Hi Willem, See attached for a revised patch. Some of the tests failed when the JDK does not have unlimited security policies installed. Thanks, Colm. Add support for more/new encryption/signature algorithms Key: CAMEL-7948 URL: https://issues.apache.org/jira/browse/CAMEL-7948 Project: Camel Issue Type: Improvement Components: camel-xmlsecurity Reporter: Colm O hEigeartaigh Assignee: Willem Jiang Priority: Minor Attachments: camel-7498-revised.patch, camel-7948.patch See attached for a patch to support some new (to XML Security) digest algorithms such as RIPE-MD160 and SEED + CAMELLIA encryption algorithms. Also added a fairly comprehensive set of tests for different encryption/signature algorithms. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-7916) OsgiServiceRegistry forces name property
[ https://issues.apache.org/jira/browse/CAMEL-7916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14182809#comment-14182809 ] Willem Jiang commented on CAMEL-7916: - I don't think we need to use System.identityHashCode for it as the map is created per invocation. OsgiServiceRegistry forces name property Key: CAMEL-7916 URL: https://issues.apache.org/jira/browse/CAMEL-7916 Project: Camel Issue Type: Bug Components: osgi Affects Versions: 2.14.0 Reporter: Benjamin Graf Assignee: Willem Jiang Fix For: 2.13.3, 2.14.1, 2.15.0 Several components does search the registry by calling findByTypeWithName. This method needs in OsgiServiceRegistry that every service has a name property which is not forced by spec and therefor optional. Maybe add a different name in those cases. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-7949) JmsMessageHelper to support automatic conversion from ByteBuffer to BytesMessage
[ https://issues.apache.org/jira/browse/CAMEL-7949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-7949: --- Priority: Minor (was: Critical) JmsMessageHelper to support automatic conversion from ByteBuffer to BytesMessage Key: CAMEL-7949 URL: https://issues.apache.org/jira/browse/CAMEL-7949 Project: Camel Issue Type: Improvement Components: camel-sjms Affects Versions: 2.14.0 Reporter: Aaron Whiteside Priority: Minor JmsMessageHelper to support automatic conversion from ByteBuffer to BytesMessage. Looking at the code, byte[] and InputStream conversion to BytesMessage could utilize camel's built in type conversion functionality and not reimplement it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-7948) Add support for more/new encryption/signature algorithms
[ https://issues.apache.org/jira/browse/CAMEL-7948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Willem Jiang resolved CAMEL-7948. - Resolution: Fixed Fix Version/s: 2.15.0 Applied the patch in Camel master branch with thanks to Colm. Add support for more/new encryption/signature algorithms Key: CAMEL-7948 URL: https://issues.apache.org/jira/browse/CAMEL-7948 Project: Camel Issue Type: Improvement Components: camel-xmlsecurity Reporter: Colm O hEigeartaigh Assignee: Willem Jiang Priority: Minor Fix For: 2.15.0 Attachments: camel-7498-revised.patch, camel-7948.patch See attached for a patch to support some new (to XML Security) digest algorithms such as RIPE-MD160 and SEED + CAMELLIA encryption algorithms. Also added a fairly comprehensive set of tests for different encryption/signature algorithms. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-7926) header CamelFileLastModified returned as String in Processor
[
https://issues.apache.org/jira/browse/CAMEL-7926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen resolved CAMEL-7926.
Resolution: Invalid
header CamelFileLastModified returned as String in Processor
--
Key: CAMEL-7926
URL: https://issues.apache.org/jira/browse/CAMEL-7926
Project: Camel
Issue Type: Bug
Affects Versions: 2.8.6
Reporter: Alexandru Repede
Priority: Minor
Given a class that implements _Processor_
When trying to get _Exchange.FILE_LAST_MODIFIED_ as a java.util.Date, the
result is null. When calling
{noformat}
Date lastModification =
exchange.getIn().getHeader(Exchange.FILE_LAST_MODIFIED, Date.class);
{noformat}
_lastModification_ is null.
Upon debugging, discovered that the header in question is a String. The call
{noformat}
exchange.getIn().getHeader(Exchange.FILE_LAST_MODIFIED)
{noformat}
returns a not null String value.
How is this possible when even _ExpressionBuilder.dateExpression_ does
{noformat}
Date date;
date = exchange.getIn().getHeader(Exchange.FILE_LAST_MODIFIED, Date.class);
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-7926) header CamelFileLastModified returned as String in Processor
[
https://issues.apache.org/jira/browse/CAMEL-7926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14182825#comment-14182825
]
Claus Ibsen commented on CAMEL-7926:
Please use the user forum / mailing list for questions / help with this.
header CamelFileLastModified returned as String in Processor
--
Key: CAMEL-7926
URL: https://issues.apache.org/jira/browse/CAMEL-7926
Project: Camel
Issue Type: Bug
Affects Versions: 2.8.6
Reporter: Alexandru Repede
Priority: Minor
Given a class that implements _Processor_
When trying to get _Exchange.FILE_LAST_MODIFIED_ as a java.util.Date, the
result is null. When calling
{noformat}
Date lastModification =
exchange.getIn().getHeader(Exchange.FILE_LAST_MODIFIED, Date.class);
{noformat}
_lastModification_ is null.
Upon debugging, discovered that the header in question is a String. The call
{noformat}
exchange.getIn().getHeader(Exchange.FILE_LAST_MODIFIED)
{noformat}
returns a not null String value.
How is this possible when even _ExpressionBuilder.dateExpression_ does
{noformat}
Date date;
date = exchange.getIn().getHeader(Exchange.FILE_LAST_MODIFIED, Date.class);
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CAMEL-7939) Pluggable RedeliveryStrategy for RedeliveryErrorHandler
[ https://issues.apache.org/jira/browse/CAMEL-7939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-7939: --- Priority: Major (was: Critical) Pluggable RedeliveryStrategy for RedeliveryErrorHandler --- Key: CAMEL-7939 URL: https://issues.apache.org/jira/browse/CAMEL-7939 Project: Camel Issue Type: Improvement Components: camel-core Affects Versions: 2.14.0 Reporter: Aaron Whiteside Pluggable RedeliveryStrategy for RedeliveryErrorHandler The logic of calling executorService.schedule() and RedeliveryPolicy.sleep() in RedeliveryErrorHandler.process() and executorService.schedule()/submit() in RedeliveryErrorHandler.processAsyncErrorHandler() should be abstracted into a RedeliveryStrategy. The use case for this is to allow custom scheduled retries using JMS. Most if not all JMS implementations provide a vendor specific way to schedule a message for delivery at a specified time in the future. Currently we are using a custom Processor in onException() blocks (with disableRedelivery=true and handled=true) to manually schedule messages for redelivery using ProducerTemplate.send() and exchange.getFromEndpoint(). However this does not play well with Camel's built in Exchange Properties that deal with retry count, retry delay, etc and we have ended up duplicating camel's build in properties using our own custom properties. So that the various interceptors don't strip them.. and not to mention we have ended up duplicating a large portion of the RedeliveryErrorHandler's logic in our own Processor. We do not use camel's built in synchronous retry because it blocks the calling thread and we do no use the async scheduled retry because it is not safe, Exchange's are not persisted and when the context is shutdown they will be lost (camel's DefaultShutdownStrategy with a timeout does not help, it's not always possible to get an exchange accepted by an endpoint before shutting down - Think HTTP notifications to clients...) And we do not use our JMS vendors automatic retry mechanism, because it means we lose control of the retries on a per route basis (all retry options must be configured and administered on the broker side). And there is no metadata in the Exchange about the retry count, message history, etc.. as the original message is redelivered (transaction rollback/unacked etc). If the actual logic of sending and scheduling retries was abstracted we could plug in our own strategy to do this based on our JMS vendor (HornetQ). I imagine that our implementation would be almost identical for ActiveMQ too (different JMS header). And we would be willing to submit it back to the Camel Project. We would also be willing to submit a patch to pull out logic into a RedeliveryStrategy, just need a little guidance. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-7939) Pluggable RedeliveryStrategy for RedeliveryErrorHandler
[ https://issues.apache.org/jira/browse/CAMEL-7939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-7939: --- Estimated Complexity: Advanced (was: Moderate) Pluggable RedeliveryStrategy for RedeliveryErrorHandler --- Key: CAMEL-7939 URL: https://issues.apache.org/jira/browse/CAMEL-7939 Project: Camel Issue Type: New Feature Components: camel-core Affects Versions: 2.14.0 Reporter: Aaron Whiteside Pluggable RedeliveryStrategy for RedeliveryErrorHandler The logic of calling executorService.schedule() and RedeliveryPolicy.sleep() in RedeliveryErrorHandler.process() and executorService.schedule()/submit() in RedeliveryErrorHandler.processAsyncErrorHandler() should be abstracted into a RedeliveryStrategy. The use case for this is to allow custom scheduled retries using JMS. Most if not all JMS implementations provide a vendor specific way to schedule a message for delivery at a specified time in the future. Currently we are using a custom Processor in onException() blocks (with disableRedelivery=true and handled=true) to manually schedule messages for redelivery using ProducerTemplate.send() and exchange.getFromEndpoint(). However this does not play well with Camel's built in Exchange Properties that deal with retry count, retry delay, etc and we have ended up duplicating camel's build in properties using our own custom properties. So that the various interceptors don't strip them.. and not to mention we have ended up duplicating a large portion of the RedeliveryErrorHandler's logic in our own Processor. We do not use camel's built in synchronous retry because it blocks the calling thread and we do no use the async scheduled retry because it is not safe, Exchange's are not persisted and when the context is shutdown they will be lost (camel's DefaultShutdownStrategy with a timeout does not help, it's not always possible to get an exchange accepted by an endpoint before shutting down - Think HTTP notifications to clients...) And we do not use our JMS vendors automatic retry mechanism, because it means we lose control of the retries on a per route basis (all retry options must be configured and administered on the broker side). And there is no metadata in the Exchange about the retry count, message history, etc.. as the original message is redelivered (transaction rollback/unacked etc). If the actual logic of sending and scheduling retries was abstracted we could plug in our own strategy to do this based on our JMS vendor (HornetQ). I imagine that our implementation would be almost identical for ActiveMQ too (different JMS header). And we would be willing to submit it back to the Camel Project. We would also be willing to submit a patch to pull out logic into a RedeliveryStrategy, just need a little guidance. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-7939) Pluggable RedeliveryStrategy for RedeliveryErrorHandler
[ https://issues.apache.org/jira/browse/CAMEL-7939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Claus Ibsen updated CAMEL-7939: --- Issue Type: New Feature (was: Improvement) Pluggable RedeliveryStrategy for RedeliveryErrorHandler --- Key: CAMEL-7939 URL: https://issues.apache.org/jira/browse/CAMEL-7939 Project: Camel Issue Type: New Feature Components: camel-core Affects Versions: 2.14.0 Reporter: Aaron Whiteside Pluggable RedeliveryStrategy for RedeliveryErrorHandler The logic of calling executorService.schedule() and RedeliveryPolicy.sleep() in RedeliveryErrorHandler.process() and executorService.schedule()/submit() in RedeliveryErrorHandler.processAsyncErrorHandler() should be abstracted into a RedeliveryStrategy. The use case for this is to allow custom scheduled retries using JMS. Most if not all JMS implementations provide a vendor specific way to schedule a message for delivery at a specified time in the future. Currently we are using a custom Processor in onException() blocks (with disableRedelivery=true and handled=true) to manually schedule messages for redelivery using ProducerTemplate.send() and exchange.getFromEndpoint(). However this does not play well with Camel's built in Exchange Properties that deal with retry count, retry delay, etc and we have ended up duplicating camel's build in properties using our own custom properties. So that the various interceptors don't strip them.. and not to mention we have ended up duplicating a large portion of the RedeliveryErrorHandler's logic in our own Processor. We do not use camel's built in synchronous retry because it blocks the calling thread and we do no use the async scheduled retry because it is not safe, Exchange's are not persisted and when the context is shutdown they will be lost (camel's DefaultShutdownStrategy with a timeout does not help, it's not always possible to get an exchange accepted by an endpoint before shutting down - Think HTTP notifications to clients...) And we do not use our JMS vendors automatic retry mechanism, because it means we lose control of the retries on a per route basis (all retry options must be configured and administered on the broker side). And there is no metadata in the Exchange about the retry count, message history, etc.. as the original message is redelivered (transaction rollback/unacked etc). If the actual logic of sending and scheduling retries was abstracted we could plug in our own strategy to do this based on our JMS vendor (HornetQ). I imagine that our implementation would be almost identical for ActiveMQ too (different JMS header). And we would be willing to submit it back to the Camel Project. We would also be willing to submit a patch to pull out logic into a RedeliveryStrategy, just need a little guidance. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-6406) Add support to ObjectHelper.getException() for Java 1.7 Throwable.getSuppressed()
[ https://issues.apache.org/jira/browse/CAMEL-6406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14183030#comment-14183030 ] Aaron Whiteside commented on CAMEL-6406: getSuppressed() is not the same thing as getCause(). Causes are chained, suppressed exceptions are well suppressed.. Typically you would call exception.addSuppressed(x); this happens in with things like the try with resource block. Or more typically when you catch an exception and must close some resource that who's close method also throws an exception, gone are the days when you would ignore that nested exception, now you can call addSuppressed() to the original exception. Add support to ObjectHelper.getException() for Java 1.7 Throwable.getSuppressed() - Key: CAMEL-6406 URL: https://issues.apache.org/jira/browse/CAMEL-6406 Project: Camel Issue Type: Improvement Components: camel-core Affects Versions: 2.11.0, 2.14.0 Reporter: Aaron Whiteside Assignee: Willem Jiang Add support to ObjectHelper.getException() for Java 1.7 Throwable.getSuppressed() Now that exceptions can be suppressed in Java 1.7 Camel should be able to detect when running in a 1.7 JVM and use the additional suppressed Throwables when searching for specific exception types. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (CAMEL-6406) Add support to ObjectHelper.getException() for Java 1.7 Throwable.getSuppressed()
[ https://issues.apache.org/jira/browse/CAMEL-6406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14183030#comment-14183030 ] Aaron Whiteside edited comment on CAMEL-6406 at 10/24/14 4:51 PM: -- getSuppressed() is not the same thing as getCause(). Causes are chained, suppressed exceptions are well suppressed.. Typically you would call exception.addSuppressed( x ); this happens automatically with a try-with-resource block. Or more typically when you catch an exception and must close some resource who's close method also throws an exception, gone are the days when you would ignore that nested exception, now you can call addSuppressed() to the original exception. http://docs.oracle.com/javase/7/docs/api/java/lang/Throwable.html#addSuppressed(java.lang.Throwable) was (Author: aaronjwhiteside): getSuppressed() is not the same thing as getCause(). Causes are chained, suppressed exceptions are well suppressed.. Typically you would call exception.addSuppressed( x ); this happens automatically with a try-with-resource block. Or more typically when you catch an exception and must close some resource who's close method also throws an exception, gone are the days when you would ignore that nested exception, now you can call addSuppressed() to the original exception. Add support to ObjectHelper.getException() for Java 1.7 Throwable.getSuppressed() - Key: CAMEL-6406 URL: https://issues.apache.org/jira/browse/CAMEL-6406 Project: Camel Issue Type: Improvement Components: camel-core Affects Versions: 2.11.0, 2.14.0 Reporter: Aaron Whiteside Assignee: Willem Jiang Add support to ObjectHelper.getException() for Java 1.7 Throwable.getSuppressed() Now that exceptions can be suppressed in Java 1.7 Camel should be able to detect when running in a 1.7 JVM and use the additional suppressed Throwables when searching for specific exception types. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CAMEL-7952) Camel REST does not handle same path with differents VERBS
[
https://issues.apache.org/jira/browse/CAMEL-7952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre-Alban DEWITTE closed CAMEL-7952.
---
Thanks, it is working like a charm now.
Camel REST does not handle same path with differents VERBS
--
Key: CAMEL-7952
URL: https://issues.apache.org/jira/browse/CAMEL-7952
Project: Camel
Issue Type: Bug
Components: camel-core
Affects Versions: 2.14.0
Environment: ALL
Reporter: Pierre-Alban DEWITTE
Assignee: Willem Jiang
Fix For: 2.14.1, 2.15.0
If we had the same path with different verbs (GET, POST, DELETE) only one is
randomly choosen.
To reproduce this issue i just changed the route builder in
camel-example-servlet-rest-tomcat.
In UserRouteBuilder.java change the last statement of configure() method
with :
rest(/user).description(User rest service)
.consumes(application/json).produces(application/json)
.get(/name).description(GET).outTypeList(User.class)
.to(bean:userService?method=listUsers)
.post(/name).description(POST).to(bean:userService?method=listUsers)
.delete(/{name}).description(DELETE).to(bean:userService?method=listUsers)
;
After a quick debug it seams that the CamelServlet is fiiling a map of
HttpConsumer. The key is path so only last one can be used further.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CAMEL-7954) Camel-box should create https connections using SSLContextParameters
Dhiraj Bokde created CAMEL-7954: --- Summary: Camel-box should create https connections using SSLContextParameters Key: CAMEL-7954 URL: https://issues.apache.org/jira/browse/CAMEL-7954 Project: Camel Issue Type: Bug Reporter: Dhiraj Bokde Assignee: Dhiraj Bokde Currently camel-olingo2 uses SSLContext directly to create connections; it should use SSLContextParameters. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-7955) Camel-linkedin should create https connections using SSLContextParameters
Dhiraj Bokde created CAMEL-7955: --- Summary: Camel-linkedin should create https connections using SSLContextParameters Key: CAMEL-7955 URL: https://issues.apache.org/jira/browse/CAMEL-7955 Project: Camel Issue Type: Bug Reporter: Dhiraj Bokde Assignee: Dhiraj Bokde Currently camel-olingo2 uses SSLContext directly to create connections; it should use SSLContextParameters. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-7956) Camel-salesforce should create https connections using SSLContextParameters
Dhiraj Bokde created CAMEL-7956: --- Summary: Camel-salesforce should create https connections using SSLContextParameters Key: CAMEL-7956 URL: https://issues.apache.org/jira/browse/CAMEL-7956 Project: Camel Issue Type: Bug Reporter: Dhiraj Bokde Assignee: Dhiraj Bokde Currently camel-olingo2 uses SSLContext directly to create connections; it should use SSLContextParameters. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-7934) Camel-olingo2 should create https connections using SSLContextParameters
[ https://issues.apache.org/jira/browse/CAMEL-7934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dhiraj Bokde updated CAMEL-7934: Issue Type: Sub-task (was: Bug) Parent: CAMEL-7957 Camel-olingo2 should create https connections using SSLContextParameters Key: CAMEL-7934 URL: https://issues.apache.org/jira/browse/CAMEL-7934 Project: Camel Issue Type: Sub-task Reporter: Chess Hazlett Assignee: Dhiraj Bokde Currently camel-olingo2 uses SSLContext directly to create connections; it should use SSLContextParameters. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-7957) Standardize Camel components to use SSLContextParameters
Dhiraj Bokde created CAMEL-7957: --- Summary: Standardize Camel components to use SSLContextParameters Key: CAMEL-7957 URL: https://issues.apache.org/jira/browse/CAMEL-7957 Project: Camel Issue Type: Bug Affects Versions: 2.14.0, 2.13.2 Reporter: Dhiraj Bokde Assignee: Dhiraj Bokde Fix For: 2.13.3, 2.14.1, 2.15.0 Some Camel components create HTTP connections using default SSLContext settings. Components should standardize on using SSLContextParameters, especially for [CAMEL-7940]. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-7954) Camel-box should create https connections using SSLContextParameters
[ https://issues.apache.org/jira/browse/CAMEL-7954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dhiraj Bokde updated CAMEL-7954: Issue Type: Sub-task (was: Bug) Parent: CAMEL-7957 Camel-box should create https connections using SSLContextParameters Key: CAMEL-7954 URL: https://issues.apache.org/jira/browse/CAMEL-7954 Project: Camel Issue Type: Sub-task Reporter: Dhiraj Bokde Assignee: Dhiraj Bokde Currently camel-olingo2 uses SSLContext directly to create connections; it should use SSLContextParameters. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-7955) Camel-linkedin should create https connections using SSLContextParameters
[ https://issues.apache.org/jira/browse/CAMEL-7955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dhiraj Bokde updated CAMEL-7955: Issue Type: Sub-task (was: Bug) Parent: CAMEL-7957 Camel-linkedin should create https connections using SSLContextParameters - Key: CAMEL-7955 URL: https://issues.apache.org/jira/browse/CAMEL-7955 Project: Camel Issue Type: Sub-task Reporter: Dhiraj Bokde Assignee: Dhiraj Bokde Currently camel-olingo2 uses SSLContext directly to create connections; it should use SSLContextParameters. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-7956) Camel-salesforce should create https connections using SSLContextParameters
[ https://issues.apache.org/jira/browse/CAMEL-7956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dhiraj Bokde updated CAMEL-7956: Issue Type: Sub-task (was: Bug) Parent: CAMEL-7957 Camel-salesforce should create https connections using SSLContextParameters --- Key: CAMEL-7956 URL: https://issues.apache.org/jira/browse/CAMEL-7956 Project: Camel Issue Type: Sub-task Reporter: Dhiraj Bokde Assignee: Dhiraj Bokde Currently camel-olingo2 uses SSLContext directly to create connections; it should use SSLContextParameters. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-7933) Camel-apns should create https connections using SSLContextParameters
[ https://issues.apache.org/jira/browse/CAMEL-7933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dhiraj Bokde updated CAMEL-7933: Issue Type: Sub-task (was: Bug) Parent: CAMEL-7957 Camel-apns should create https connections using SSLContextParameters - Key: CAMEL-7933 URL: https://issues.apache.org/jira/browse/CAMEL-7933 Project: Camel Issue Type: Sub-task Components: camel-apns Reporter: Chess Hazlett Assignee: Dhiraj Bokde Currently camel-apns uses SSLContext directly to create connections; it should use SSLContextParameters. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-7954) Camel-box should create https connections using SSLContextParameters
[ https://issues.apache.org/jira/browse/CAMEL-7954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14183576#comment-14183576 ] Dhiraj Bokde commented on CAMEL-7954: - Component updated, need to update documentation Camel-box should create https connections using SSLContextParameters Key: CAMEL-7954 URL: https://issues.apache.org/jira/browse/CAMEL-7954 Project: Camel Issue Type: Sub-task Reporter: Dhiraj Bokde Assignee: Dhiraj Bokde Currently camel-olingo2 uses SSLContext directly to create connections; it should use SSLContextParameters. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-7955) Camel-linkedin should create https connections using SSLContextParameters
[ https://issues.apache.org/jira/browse/CAMEL-7955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dhiraj Bokde resolved CAMEL-7955. - Resolution: Fixed Component updated, no documentation update needed Camel-linkedin should create https connections using SSLContextParameters - Key: CAMEL-7955 URL: https://issues.apache.org/jira/browse/CAMEL-7955 Project: Camel Issue Type: Sub-task Reporter: Dhiraj Bokde Assignee: Dhiraj Bokde Currently camel-olingo2 uses SSLContext directly to create connections; it should use SSLContextParameters. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-7934) Camel-olingo2 should create https connections using SSLContextParameters
[ https://issues.apache.org/jira/browse/CAMEL-7934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14183575#comment-14183575 ] Dhiraj Bokde commented on CAMEL-7934: - Component updated, need to update documentation Camel-olingo2 should create https connections using SSLContextParameters Key: CAMEL-7934 URL: https://issues.apache.org/jira/browse/CAMEL-7934 Project: Camel Issue Type: Sub-task Reporter: Chess Hazlett Assignee: Dhiraj Bokde Currently camel-olingo2 uses SSLContext directly to create connections; it should use SSLContextParameters. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-7956) Camel-salesforce should create https connections using SSLContextParameters
[ https://issues.apache.org/jira/browse/CAMEL-7956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14183580#comment-14183580 ] Dhiraj Bokde commented on CAMEL-7956: - Component updated, need to update documentation Camel-salesforce should create https connections using SSLContextParameters --- Key: CAMEL-7956 URL: https://issues.apache.org/jira/browse/CAMEL-7956 Project: Camel Issue Type: Sub-task Reporter: Dhiraj Bokde Assignee: Dhiraj Bokde Currently camel-olingo2 uses SSLContext directly to create connections; it should use SSLContextParameters. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-7933) Camel-apns should create https connections using SSLContextParameters
[ https://issues.apache.org/jira/browse/CAMEL-7933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14183582#comment-14183582 ] Dhiraj Bokde commented on CAMEL-7933: - Component updated, need to update documentation Camel-apns should create https connections using SSLContextParameters - Key: CAMEL-7933 URL: https://issues.apache.org/jira/browse/CAMEL-7933 Project: Camel Issue Type: Sub-task Components: camel-apns Reporter: Chess Hazlett Assignee: Dhiraj Bokde Currently camel-apns uses SSLContext directly to create connections; it should use SSLContextParameters. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
