[jira] [Created] (CAMEL-7935) JcloudsPayloadConverter.toPayload(InputStream) cannot deal with FileInputStreamCache
Willem Jiang created CAMEL-7935: --- Summary: JcloudsPayloadConverter.toPayload(InputStream) cannot deal with FileInputStreamCache Key: CAMEL-7935 URL: https://issues.apache.org/jira/browse/CAMEL-7935 Project: Camel Issue Type: Bug Components: camel-jclouds Affects Versions: 2.14.0, 2.13.2 Reporter: Willem Jiang Assignee: Willem Jiang Fix For: 2.13.3, 2.14.1, 2.15.0 StackOverflowError if body is FileInputStreamCache. http://camel.465427.n5.nabble.com/camel-jclouds-StackOverflowError-if-body-is-FileInputStreamCache-tp5757810.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-7936) Add support for Query Params in the REST DSL
Espen Tjonneland created CAMEL-7936: --- Summary: Add support for Query Params in the REST DSL Key: CAMEL-7936 URL: https://issues.apache.org/jira/browse/CAMEL-7936 Project: Camel Issue Type: New Feature Components: camel-core, camel-swagger Affects Versions: 2.14.0 Reporter: Espen Tjonneland Query parameters are currently supported implicitly through HTTP Headers. However, this does not play very well with the new Swagger component. Without the declarative support of query params in the Rest DSL camel-swagger cannot add that information to the REST-description (api-docs). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-4494) Allow replyTo message header to be different from actual reply queue
[ https://issues.apache.org/jira/browse/CAMEL-4494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14178090#comment-14178090 ] Willem Jiang commented on CAMEL-4494: - Hi Jens, Current Apache JIRA just takes the submit action as granted with Apache license, so you don't need to do anything else this time. Regards, Willem Allow replyTo message header to be different from actual reply queue Key: CAMEL-4494 URL: https://issues.apache.org/jira/browse/CAMEL-4494 Project: Camel Issue Type: New Feature Components: camel-jms Affects Versions: 2.8.1 Reporter: Jens Granseuer Attachments: camel-jms-replyto.diff, camel-jms-replyto2.diff We have an application that acts as a JMS client in the following setup: * a local queue manager (L) with queues for request (L.REQUEST) and reply (L.REPLY) messages * a remote queue manager (R) with queues for request (R.REQUEST) and reply (R.REPLY) messages The remote queue manager is unknown to the client application, and messages sent to L.REQUEST are automatically forwarded to R.REQUEST. Similarly, there is a server application listening on R.REQUEST, posting responses in R.REPLY. The local queue manager is unknown to the server application. Messages sent to R.REPLY are automatically forwarded to L.REPLY. The client needs to put message in L.REQUEST and receive the reply in L.REPLY. However, in the message header it must set R.REPLY as the reply queue because L.REPLY is not known to the server application. The Camel JMS component currently doesn't seem to support this scenario. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-7834) create a docker events endpoint
[ https://issues.apache.org/jira/browse/CAMEL-7834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14178093#comment-14178093 ] Willem Jiang commented on CAMEL-7834: - Hi Andy Thanks for you contribution. I just have a quick look at the components and check the dependency of docker-java, they are good. The only missing part you need to Add the Apache Header to java files in your repo. You can send a pull request based on Camel master branch once you updated the java files. I’d happy to merge the patch into camel master for you. Regards, Willem create a docker events endpoint --- Key: CAMEL-7834 URL: https://issues.apache.org/jira/browse/CAMEL-7834 Project: Camel Issue Type: New Feature Reporter: james strachan Docker provides a REST API to query events (for containers starting and stopping etc): https://docs.docker.com/reference/api/docker_remote_api_v1.14/#monitor-dockers-events it'd be nice to support a simple camel component to make it easier to consume docker events; with the events available as a JSON String or as a POJO -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-4494) Allow replyTo message header to be different from actual reply queue
[ https://issues.apache.org/jira/browse/CAMEL-4494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Granseuer updated CAMEL-4494: -- Attachment: camel-jms-replyto2.diff reattached with license grant Allow replyTo message header to be different from actual reply queue Key: CAMEL-4494 URL: https://issues.apache.org/jira/browse/CAMEL-4494 Project: Camel Issue Type: New Feature Components: camel-jms Affects Versions: 2.8.1 Reporter: Jens Granseuer Attachments: camel-jms-replyto.diff, camel-jms-replyto2.diff, camel-jms-replyto2.diff We have an application that acts as a JMS client in the following setup: * a local queue manager (L) with queues for request (L.REQUEST) and reply (L.REPLY) messages * a remote queue manager (R) with queues for request (R.REQUEST) and reply (R.REPLY) messages The remote queue manager is unknown to the client application, and messages sent to L.REQUEST are automatically forwarded to R.REQUEST. Similarly, there is a server application listening on R.REQUEST, posting responses in R.REPLY. The local queue manager is unknown to the server application. Messages sent to R.REPLY are automatically forwarded to L.REPLY. The client needs to put message in L.REQUEST and receive the reply in L.REPLY. However, in the message header it must set R.REPLY as the reply queue because L.REPLY is not known to the server application. The Camel JMS component currently doesn't seem to support this scenario. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-7883) XSD decoding bad guess in Validator
[ https://issues.apache.org/jira/browse/CAMEL-7883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14178135#comment-14178135 ] ASF GitHub Bot commented on CAMEL-7883: --- Github user bonnetb closed the pull request at: https://github.com/apache/camel/pull/291 XSD decoding bad guess in Validator --- Key: CAMEL-7883 URL: https://issues.apache.org/jira/browse/CAMEL-7883 Project: Camel Issue Type: Bug Components: camel-core Affects Versions: 2.13.2, 2.14.0 Reporter: Benjamin BONNET Assignee: Willem Jiang Fix For: 2.13.3, 2.14.1, 2.15.0 Validator component does not take imported XSD encoding into account when validating XML. That may lead to validation errors if an imported XSD is ISO-8859-1 encoded and containing non ASCII caracters, even though that XSD declares its encoding correctly in its XML prolog. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CAMEL-7701) Chaining cxfrs endpoints
[ https://issues.apache.org/jira/browse/CAMEL-7701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin BONNET closed CAMEL-7701. -- Chaining cxfrs endpoints Key: CAMEL-7701 URL: https://issues.apache.org/jira/browse/CAMEL-7701 Project: Camel Issue Type: Bug Components: camel-cxf Affects Versions: 2.13.2, Future Environment: JDK7 / Windows7 OpenJDK /Ubuntu Precise Reporter: Benjamin BONNET Assignee: Willem Jiang Fix For: 2.12.5, 2.13.3, 2.14.0 Hi, chaining 2 cxfrs endpoints in a route reveals 2 problems : - proxy-client method choice in producer (CxfRsProducer.findRightMethod) is way too restrictive : the choice is based on the name and the exact type of the parameters. As a consequence, if parameters type transmitted are compatible (i.e. extend the signature parameter types) with the method signature but are not the very ones of the signature, the operation will not be found. That problem occurs when you chain 2 cxfrs endpoints having an InputStream parameter since cxf uses DelegatingInputStream to handle received InputStreams. That problem may also occur for any .to() cxfrs endpoint if the message body uses subtypes of the parameters. - transmitting Content-Type header from camel to CXFRS request in DefaultCxfRsBinding may cause trouble for multipart messages : actually, if Content-Type contains a boundary defintion (which is the case when you chain cxfrs endpoints), that definition will be included into the Content-Type transmitted (in addition with the one generated during binding). That throws an exception since the old boundary is not used in the transmitted message. NB : header propagation was not enforced in 2.13.2 but it is enforced in head. I developped a JUnit test that shows such failures in the case of a cxfrs endpoint chaining, and some code that prevents them. I am going to submit them on github. Regards -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CAMEL-7883) XSD decoding bad guess in Validator
[ https://issues.apache.org/jira/browse/CAMEL-7883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin BONNET closed CAMEL-7883. -- Thank you Willem XSD decoding bad guess in Validator --- Key: CAMEL-7883 URL: https://issues.apache.org/jira/browse/CAMEL-7883 Project: Camel Issue Type: Bug Components: camel-core Affects Versions: 2.13.2, 2.14.0 Reporter: Benjamin BONNET Assignee: Willem Jiang Fix For: 2.13.3, 2.14.1, 2.15.0 Validator component does not take imported XSD encoding into account when validating XML. That may lead to validation errors if an imported XSD is ISO-8859-1 encoded and containing non ASCII caracters, even though that XSD declares its encoding correctly in its XML prolog. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CAMEL-4494) Allow replyTo message header to be different from actual reply queue
[ https://issues.apache.org/jira/browse/CAMEL-4494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Willem Jiang reassigned CAMEL-4494: --- Assignee: Willem Jiang Allow replyTo message header to be different from actual reply queue Key: CAMEL-4494 URL: https://issues.apache.org/jira/browse/CAMEL-4494 Project: Camel Issue Type: New Feature Components: camel-jms Affects Versions: 2.8.1 Reporter: Jens Granseuer Assignee: Willem Jiang Attachments: camel-jms-replyto.diff, camel-jms-replyto2.diff, camel-jms-replyto2.diff We have an application that acts as a JMS client in the following setup: * a local queue manager (L) with queues for request (L.REQUEST) and reply (L.REPLY) messages * a remote queue manager (R) with queues for request (R.REQUEST) and reply (R.REPLY) messages The remote queue manager is unknown to the client application, and messages sent to L.REQUEST are automatically forwarded to R.REQUEST. Similarly, there is a server application listening on R.REQUEST, posting responses in R.REPLY. The local queue manager is unknown to the server application. Messages sent to R.REPLY are automatically forwarded to L.REPLY. The client needs to put message in L.REQUEST and receive the reply in L.REPLY. However, in the message header it must set R.REPLY as the reply queue because L.REPLY is not known to the server application. The Camel JMS component currently doesn't seem to support this scenario. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-7937) camel-example-cdi fails on wildfly
Thomas Diesler created CAMEL-7937:
-
Summary: camel-example-cdi fails on wildfly
Key: CAMEL-7937
URL: https://issues.apache.org/jira/browse/CAMEL-7937
Project: Camel
Issue Type: Bug
Affects Versions: 2.14.0
Reporter: Thomas Diesler
[.. camel-example-cdi]$ mvn clean install -Parquillian-jbossas-managed
{code}
Caused by: java.lang.IllegalArgumentException: Packaging type jdocbook is not
supported.
at
org.jboss.shrinkwrap.resolver.api.maven.PackagingType.fromPackagingType(PackagingType.java:65)
at
org.jboss.shrinkwrap.resolver.impl.maven.convert.MavenConverter.fromDependency(MavenConverter.java:149)
at
org.jboss.shrinkwrap.resolver.impl.maven.convert.MavenConverter.fromDependencies(MavenConverter.java:163)
at
org.jboss.shrinkwrap.resolver.impl.maven.PomEquippedResolveStageBaseImpl.init(PomEquippedResolveStageBaseImpl.java:68)
at
org.jboss.shrinkwrap.resolver.impl.maven.PomEquippedResolveStageImpl.init(PomEquippedResolveStageImpl.java:38)
at
org.jboss.shrinkwrap.resolver.impl.maven.PomlessResolveStageImpl.createNewPomEquippedResolveStage(PomlessResolveStageImpl.java:55)
at
org.jboss.shrinkwrap.resolver.impl.maven.PomlessResolveStageImpl.createNewPomEquippedResolveStage(PomlessResolveStageImpl.java:30)
at
org.jboss.shrinkwrap.resolver.impl.maven.PomlessResolveStageBaseImpl.loadPomFromFile(PomlessResolveStageBaseImpl.java:77)
at
org.jboss.shrinkwrap.resolver.impl.maven.PomlessResolveStageBaseImpl.loadPomFromFile(PomlessResolveStageBaseImpl.java:99)
at
org.jboss.shrinkwrap.resolver.impl.maven.MavenResolverSystemBaseImpl.loadPomFromFile(MavenResolverSystemBaseImpl.java:157)
at
org.apache.camel.example.cdi.ArchiveUtil.createWarArchive(ArchiveUtil.java:61)
at
org.apache.camel.example.cdi.one.DeploymentFactory.createArchive(DeploymentFactory.java:48)
{code}
{code}
Tests in error:
IntegrationTest.org.apache.camel.example.cdi.one.IntegrationTest » Runtime
Cou...
SeparateRouteBuilderIntegrationTest.org.apache.camel.example.cdi.two.SeparateRouteBuilderIntegrationTest
» Runtime
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CAMEL-7895) Upgrade XML Security + BouncyCastle dependencies
[ https://issues.apache.org/jira/browse/CAMEL-7895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14178469#comment-14178469 ] Colm O hEigeartaigh commented on CAMEL-7895: Hi Willem, Can the patch be applied please? Colm. Upgrade XML Security + BouncyCastle dependencies Key: CAMEL-7895 URL: https://issues.apache.org/jira/browse/CAMEL-7895 Project: Camel Issue Type: Improvement Components: camel-xmlsecurity Reporter: Colm O hEigeartaigh Assignee: Willem Jiang Priority: Minor Fix For: 2.15.0 Attachments: camel-7895.patch This task is to upgrade BouncyCastle + XML Security to pick up the latest releases. The former can be applied to all branches, the latter should only be applied to 2.15 + 2.14. A patch will be attached with a test fix caused by the XML Security upgrade. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-3853) SMPP connector lazySessionCreation
[ https://issues.apache.org/jira/browse/CAMEL-3853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14178580#comment-14178580 ] Tomas Hanus commented on CAMEL-3853: Hi, now, I try to use SMPP component as producer and consumer to send SMS and PUSH SMS (MMS) to SMSC/receive delivery notifications or SMS from mobile devices. But still if SMSC is down camel context will shut down, and also all other context, so camel cannot start up. Affect version is camel 2.13.2 and only consumer. Producer is ok and parameter lazySessionCreation=true works ok, but not for consumer. Any idea how to solve lazySessionCreation=true too for consumer? SMPP connector lazySessionCreation -- Key: CAMEL-3853 URL: https://issues.apache.org/jira/browse/CAMEL-3853 Project: Camel Issue Type: New Feature Components: camel-smpp Affects Versions: 2.6.0 Reporter: Peter Argalas Assignee: Christian Müller Fix For: Future Currently I am facing issue, when connecting to SMSC using smpp conector. If SMSC is down, and smpp connection cannot be created, then camel context will shut down, and also all other context, so camel cannot start up. Camel context with smpp was set to autostart=false, but smpp still tries to create connection and fails. It would be nice to have option for lazySessionCreation like in mina. The best will be feature when smpp could start in reconnecting state (tring to connect in defined interval) in case SMSC is down. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CAMEL-7938) Crypto won't decrypt message with multiple encrypted parts if our key isn't the first part
Steve Ardis created CAMEL-7938: -- Summary: Crypto won't decrypt message with multiple encrypted parts if our key isn't the first part Key: CAMEL-7938 URL: https://issues.apache.org/jira/browse/CAMEL-7938 Project: Camel Issue Type: Bug Components: camel-crypto Affects Versions: 2.11.1 Reporter: Steve Ardis If a message has multiple PGPPublicKeyEncryptedData (meaning, multiple recipients), PGPDataFormat fails to decrypt the message (unless our key is the first PGPPublicKeyEncryptedData element). Said differently, if a message is encrypted for recipient A and B (and the encrypted parts are in that order) and we are recipient B, the message fails to decrypt. This definitely affected version 2.11.1. Looking at the latest version of the same files, this is most likely still an issue. The fix in the patch that will be supplied is currently being used in our application, but unfortunately I do not have a test case available. I will create a pull-request on Github shortly. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-7938) Crypto won't decrypt message with multiple encrypted parts if our key isn't the first part
[ https://issues.apache.org/jira/browse/CAMEL-7938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14178736#comment-14178736 ] ASF GitHub Bot commented on CAMEL-7938: --- GitHub user steveardis opened a pull request: https://github.com/apache/camel/pull/305 CAMEL-7938 - Crypto won't decrypt message with multiple encrypted parts if our key isn't the first part CAMEL-7938 patch. Note that this patch was made off the last commit in 2.11.x, based on when I actually made the fix. I'd like to see this fix move into the next possible release, so I wasn't sure which commit to actually make it against. You can merge this pull request into a Git repository by running: $ git pull https://github.com/steveardis/camel crypto_multiple_encrypted_parts Alternatively you can review and apply these changes as the patch at: https://github.com/apache/camel/pull/305.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 #305 commit 041b4591f41bef5bed9c3ff32f09973230aee5a3 Author: Steve Ardis steve.ar...@cypresscare.com Date: 2013-08-19T19:19:09Z CAMEL-7938 - Fixed issue with camel-crypto not iterating through encrypted parts and finding the one that goes with our private key; for example - if the payload was encrypted for recipients A and B (in that order), and our key is B, the private key lookup fails commit fa4b061d23dd470abcfa8849be97ba32271c4c99 Author: Steve Ardis steve.ar...@cypresscare.com Date: 2014-10-21T17:46:33Z CAMEL-7938 - Removed changes to pom.xml Crypto won't decrypt message with multiple encrypted parts if our key isn't the first part Key: CAMEL-7938 URL: https://issues.apache.org/jira/browse/CAMEL-7938 Project: Camel Issue Type: Bug Components: camel-crypto Affects Versions: 2.11.1 Reporter: Steve Ardis If a message has multiple PGPPublicKeyEncryptedData (meaning, multiple recipients), PGPDataFormat fails to decrypt the message (unless our key is the first PGPPublicKeyEncryptedData element). Said differently, if a message is encrypted for recipient A and B (and the encrypted parts are in that order) and we are recipient B, the message fails to decrypt. This definitely affected version 2.11.1. Looking at the latest version of the same files, this is most likely still an issue. The fix in the patch that will be supplied is currently being used in our application, but unfortunately I do not have a test case available. I will create a pull-request on Github shortly. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-7938) Crypto won't decrypt message with multiple encrypted parts if our key isn't the first part
[ https://issues.apache.org/jira/browse/CAMEL-7938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14178740#comment-14178740 ] Steve Ardis commented on CAMEL-7938: A pull request (#305) has been created. Crypto won't decrypt message with multiple encrypted parts if our key isn't the first part Key: CAMEL-7938 URL: https://issues.apache.org/jira/browse/CAMEL-7938 Project: Camel Issue Type: Bug Components: camel-crypto Affects Versions: 2.11.1 Reporter: Steve Ardis If a message has multiple PGPPublicKeyEncryptedData (meaning, multiple recipients), PGPDataFormat fails to decrypt the message (unless our key is the first PGPPublicKeyEncryptedData element). Said differently, if a message is encrypted for recipient A and B (and the encrypted parts are in that order) and we are recipient B, the message fails to decrypt. This definitely affected version 2.11.1. Looking at the latest version of the same files, this is most likely still an issue. The fix in the patch that will be supplied is currently being used in our application, but unfortunately I do not have a test case available. I will create a pull-request on Github shortly. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-6399) hazelcast - route policy for having one route being master, and others as slaves
[ https://issues.apache.org/jira/browse/CAMEL-6399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14178755#comment-14178755 ] Nathan Jensen commented on CAMEL-6399: -- In theory you should be able to do this using Hazelcast's Lock support. http://docs.hazelcast.org/docs/3.2/manual/html/lock.html Have a unique lock for the route, then the cluster node who successfully obtains the lock starts the route. The other nodes don't start the route but instead periodically try to obtain the lock again, so that if the former owner goes down, one of the other nodes will get the lock and start up the route. hazelcast - route policy for having one route being master, and others as slaves Key: CAMEL-6399 URL: https://issues.apache.org/jira/browse/CAMEL-6399 Project: Camel Issue Type: New Feature Components: camel-hazelcast Reporter: Claus Ibsen Fix For: Future We should look into adding a route policy functionality to camel-hazelcast. So people can use it clustered Camel apps. And have only one node run the route. And if that node dies, then another becomes master. Hazelcast may have som way of support this? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (CAMEL-7895) Upgrade XML Security + BouncyCastle dependencies
[ https://issues.apache.org/jira/browse/CAMEL-7895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Müller reassigned CAMEL-7895: --- Assignee: Christian Müller (was: Willem Jiang) Upgrade XML Security + BouncyCastle dependencies Key: CAMEL-7895 URL: https://issues.apache.org/jira/browse/CAMEL-7895 Project: Camel Issue Type: Improvement Components: camel-xmlsecurity Reporter: Colm O hEigeartaigh Assignee: Christian Müller Priority: Minor Fix For: 2.15.0 Attachments: camel-7895.patch This task is to upgrade BouncyCastle + XML Security to pick up the latest releases. The former can be applied to all branches, the latter should only be applied to 2.15 + 2.14. A patch will be attached with a test fix caused by the XML Security upgrade. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Work started] (CAMEL-7895) Upgrade XML Security + BouncyCastle dependencies
[ https://issues.apache.org/jira/browse/CAMEL-7895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on CAMEL-7895 started by Christian Müller. --- Upgrade XML Security + BouncyCastle dependencies Key: CAMEL-7895 URL: https://issues.apache.org/jira/browse/CAMEL-7895 Project: Camel Issue Type: Improvement Components: camel-xmlsecurity Reporter: Colm O hEigeartaigh Assignee: Christian Müller Priority: Minor Fix For: 2.15.0 Attachments: camel-7895.patch This task is to upgrade BouncyCastle + XML Security to pick up the latest releases. The former can be applied to all branches, the latter should only be applied to 2.15 + 2.14. A patch will be attached with a test fix caused by the XML Security upgrade. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CAMEL-7895) Upgrade XML Security + BouncyCastle dependencies
[ https://issues.apache.org/jira/browse/CAMEL-7895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14178947#comment-14178947 ] Christian Müller commented on CAMEL-7895: - Thanks for the patch Colm! I applied the patch to Camel 2.15.0 and only the BouncyCastle upgrade to camel-2.14.x and camel-2.13.x as we only include micro/patch upgrades in our maintenance branches. Upgrade XML Security + BouncyCastle dependencies Key: CAMEL-7895 URL: https://issues.apache.org/jira/browse/CAMEL-7895 Project: Camel Issue Type: Improvement Components: camel-xmlsecurity Reporter: Colm O hEigeartaigh Assignee: Christian Müller Priority: Minor Fix For: 2.15.0 Attachments: camel-7895.patch This task is to upgrade BouncyCastle + XML Security to pick up the latest releases. The former can be applied to all branches, the latter should only be applied to 2.15 + 2.14. A patch will be attached with a test fix caused by the XML Security upgrade. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CAMEL-7895) Upgrade XML Security + BouncyCastle dependencies
[ https://issues.apache.org/jira/browse/CAMEL-7895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Müller resolved CAMEL-7895. - Resolution: Fixed Fix Version/s: 2.14.1 2.13.3 Upgrade XML Security + BouncyCastle dependencies Key: CAMEL-7895 URL: https://issues.apache.org/jira/browse/CAMEL-7895 Project: Camel Issue Type: Improvement Components: camel-xmlsecurity Reporter: Colm O hEigeartaigh Assignee: Christian Müller Priority: Minor Fix For: 2.13.3, 2.14.1, 2.15.0 Attachments: camel-7895.patch This task is to upgrade BouncyCastle + XML Security to pick up the latest releases. The former can be applied to all branches, the latter should only be applied to 2.15 + 2.14. A patch will be attached with a test fix caused by the XML Security upgrade. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CAMEL-7930) org.apache.camel.itest.ftp.SpringFtpEndpointTest is failing
[
https://issues.apache.org/jira/browse/CAMEL-7930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Müller updated CAMEL-7930:
Affects Version/s: (was: 2.14.0)
Fix Version/s: 2.13.3
org.apache.camel.itest.ftp.SpringFtpEndpointTest is failing
---
Key: CAMEL-7930
URL: https://issues.apache.org/jira/browse/CAMEL-7930
Project: Camel
Issue Type: Improvement
Components: tests
Affects Versions: 2.12.3, 2.12.4, 2.12.5, 2.13.2
Environment: Java 6
Reporter: Christian Müller
Assignee: Willem Jiang
Fix For: 2.13.3
it's failing with the following stack trace:
{noformat}
java.lang.IllegalStateException: Failed to load ApplicationContext
at
org.springframework.test.context.CacheAwareContextLoaderDelegate.loadContext(CacheAwareContextLoaderDelegate.java:99)
at
org.springframework.test.context.TestContext.getApplicationContext(TestContext.java:122)
at
org.springframework.test.context.support.DependencyInjectionTestExecutionListener.injectDependencies(DependencyInjectionTestExecutionListener.java:109)
at
org.springframework.test.context.support.DependencyInjectionTestExecutionListener.prepareTestInstance(DependencyInjectionTestExecutionListener.java:75)
at
org.springframework.test.context.TestContextManager.prepareTestInstance(TestContextManager.java:321)
at
org.springframework.test.context.junit4.SpringJUnit4ClassRunner.createTest(SpringJUnit4ClassRunner.java:211)
at
org.springframework.test.context.junit4.SpringJUnit4ClassRunner$1.runReflectiveCall(SpringJUnit4ClassRunner.java:288)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.springframework.test.context.junit4.SpringJUnit4ClassRunner.methodBlock(SpringJUnit4ClassRunner.java:284)
at
org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:231)
at
org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:88)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at
org.springframework.test.context.junit4.statements.RunBeforeTestClassCallbacks.evaluate(RunBeforeTestClassCallbacks.java:61)
at
org.springframework.test.context.junit4.statements.RunAfterTestClassCallbacks.evaluate(RunAfterTestClassCallbacks.java:71)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at
org.springframework.test.context.junit4.SpringJUnit4ClassRunner.run(SpringJUnit4ClassRunner.java:174)
at
org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
at
org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
Caused by: org.springframework.beans.factory.BeanCreationException: Error
creating bean with name 'myFTPEndpoint' defined in class path resource
[org/apache/camel/itest/ftp/SpringFtpEndpointTest-context.xml]: Error setting
property values; nested exception is
org.springframework.beans.NotWritablePropertyException: Invalid property
'configuration' of bean class
[org.apache.camel.component.file.remote.FtpEndpoint]: Bean property
'configuration' is not writable or has an invalid setter method. Does the
parameter type of the setter match the return type of the getter?
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyPropertyValues(AbstractAutowireCapableBeanFactory.java:1455)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:1160)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:519)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:458)
at
[jira] [Updated] (CAMEL-7930) org.apache.camel.itest.ftp.SpringFtpEndpointTest is failing
[
https://issues.apache.org/jira/browse/CAMEL-7930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Müller updated CAMEL-7930:
Affects Version/s: (was: 2.12.5)
org.apache.camel.itest.ftp.SpringFtpEndpointTest is failing
---
Key: CAMEL-7930
URL: https://issues.apache.org/jira/browse/CAMEL-7930
Project: Camel
Issue Type: Improvement
Components: tests
Affects Versions: 2.12.3, 2.12.4, 2.13.2
Environment: Java 6
Reporter: Christian Müller
Assignee: Willem Jiang
Fix For: 2.13.3
it's failing with the following stack trace:
{noformat}
java.lang.IllegalStateException: Failed to load ApplicationContext
at
org.springframework.test.context.CacheAwareContextLoaderDelegate.loadContext(CacheAwareContextLoaderDelegate.java:99)
at
org.springframework.test.context.TestContext.getApplicationContext(TestContext.java:122)
at
org.springframework.test.context.support.DependencyInjectionTestExecutionListener.injectDependencies(DependencyInjectionTestExecutionListener.java:109)
at
org.springframework.test.context.support.DependencyInjectionTestExecutionListener.prepareTestInstance(DependencyInjectionTestExecutionListener.java:75)
at
org.springframework.test.context.TestContextManager.prepareTestInstance(TestContextManager.java:321)
at
org.springframework.test.context.junit4.SpringJUnit4ClassRunner.createTest(SpringJUnit4ClassRunner.java:211)
at
org.springframework.test.context.junit4.SpringJUnit4ClassRunner$1.runReflectiveCall(SpringJUnit4ClassRunner.java:288)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.springframework.test.context.junit4.SpringJUnit4ClassRunner.methodBlock(SpringJUnit4ClassRunner.java:284)
at
org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:231)
at
org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:88)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at
org.springframework.test.context.junit4.statements.RunBeforeTestClassCallbacks.evaluate(RunBeforeTestClassCallbacks.java:61)
at
org.springframework.test.context.junit4.statements.RunAfterTestClassCallbacks.evaluate(RunAfterTestClassCallbacks.java:71)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at
org.springframework.test.context.junit4.SpringJUnit4ClassRunner.run(SpringJUnit4ClassRunner.java:174)
at
org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
at
org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
Caused by: org.springframework.beans.factory.BeanCreationException: Error
creating bean with name 'myFTPEndpoint' defined in class path resource
[org/apache/camel/itest/ftp/SpringFtpEndpointTest-context.xml]: Error setting
property values; nested exception is
org.springframework.beans.NotWritablePropertyException: Invalid property
'configuration' of bean class
[org.apache.camel.component.file.remote.FtpEndpoint]: Bean property
'configuration' is not writable or has an invalid setter method. Does the
parameter type of the setter match the return type of the getter?
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyPropertyValues(AbstractAutowireCapableBeanFactory.java:1455)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:1160)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:519)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:458)
at
org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:293)
at
[jira] [Resolved] (CAMEL-7930) org.apache.camel.itest.ftp.SpringFtpEndpointTest is failing
[
https://issues.apache.org/jira/browse/CAMEL-7930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Müller resolved CAMEL-7930.
-
Resolution: Fixed
Fix Version/s: 2.12.5
org.apache.camel.itest.ftp.SpringFtpEndpointTest is failing
---
Key: CAMEL-7930
URL: https://issues.apache.org/jira/browse/CAMEL-7930
Project: Camel
Issue Type: Improvement
Components: tests
Affects Versions: 2.12.3, 2.12.4, 2.13.2
Environment: Java 6
Reporter: Christian Müller
Assignee: Willem Jiang
Fix For: 2.12.5, 2.13.3
it's failing with the following stack trace:
{noformat}
java.lang.IllegalStateException: Failed to load ApplicationContext
at
org.springframework.test.context.CacheAwareContextLoaderDelegate.loadContext(CacheAwareContextLoaderDelegate.java:99)
at
org.springframework.test.context.TestContext.getApplicationContext(TestContext.java:122)
at
org.springframework.test.context.support.DependencyInjectionTestExecutionListener.injectDependencies(DependencyInjectionTestExecutionListener.java:109)
at
org.springframework.test.context.support.DependencyInjectionTestExecutionListener.prepareTestInstance(DependencyInjectionTestExecutionListener.java:75)
at
org.springframework.test.context.TestContextManager.prepareTestInstance(TestContextManager.java:321)
at
org.springframework.test.context.junit4.SpringJUnit4ClassRunner.createTest(SpringJUnit4ClassRunner.java:211)
at
org.springframework.test.context.junit4.SpringJUnit4ClassRunner$1.runReflectiveCall(SpringJUnit4ClassRunner.java:288)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.springframework.test.context.junit4.SpringJUnit4ClassRunner.methodBlock(SpringJUnit4ClassRunner.java:284)
at
org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:231)
at
org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:88)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at
org.springframework.test.context.junit4.statements.RunBeforeTestClassCallbacks.evaluate(RunBeforeTestClassCallbacks.java:61)
at
org.springframework.test.context.junit4.statements.RunAfterTestClassCallbacks.evaluate(RunAfterTestClassCallbacks.java:71)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at
org.springframework.test.context.junit4.SpringJUnit4ClassRunner.run(SpringJUnit4ClassRunner.java:174)
at
org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
at
org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
Caused by: org.springframework.beans.factory.BeanCreationException: Error
creating bean with name 'myFTPEndpoint' defined in class path resource
[org/apache/camel/itest/ftp/SpringFtpEndpointTest-context.xml]: Error setting
property values; nested exception is
org.springframework.beans.NotWritablePropertyException: Invalid property
'configuration' of bean class
[org.apache.camel.component.file.remote.FtpEndpoint]: Bean property
'configuration' is not writable or has an invalid setter method. Does the
parameter type of the setter match the return type of the getter?
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.applyPropertyValues(AbstractAutowireCapableBeanFactory.java:1455)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:1160)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:519)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:458)
at
org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:293)
at
[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 ] Aaron Whiteside updated CAMEL-7939: --- Description: 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 to schedule messages for redelivery and send() them back using 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). 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. was: 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 to schedule messages for redelivery and send() them back using 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 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). 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. 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 Priority: Critical Pluggable RedeliveryStrategy for
[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 ] Aaron Whiteside updated CAMEL-7939: --- Description: 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 to schedule messages for redelivery and send() them back using 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 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). 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. was: 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 to schedule messages for redelivery and send() them back using 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.. 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). 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. 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 Priority: Critical Pluggable RedeliveryStrategy for RedeliveryErrorHandler The logic of calling executorService.schedule() and RedeliveryPolicy.sleep() in RedeliveryErrorHandler.process() and
[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 ] Aaron Whiteside updated CAMEL-7939: --- Description: 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 to schedule messages for redelivery and send() them back using 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, 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. was: 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 to schedule messages for redelivery and send() them back using 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). 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. Pluggable RedeliveryStrategy for RedeliveryErrorHandler --- Key: CAMEL-7939 URL: https://issues.apache.org/jira/browse/CAMEL-7939 Project: Camel Issue Type: Improvement Components:
[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 ] Aaron Whiteside updated CAMEL-7939: --- Description: 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, 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. was: 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 to schedule messages for redelivery and send() them back using 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, 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. Pluggable RedeliveryStrategy for RedeliveryErrorHandler
[jira] [Updated] (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 ] Aaron Whiteside updated CAMEL-6406: --- Affects Version/s: 2.14.0 Now that Camel is Java7 only, this might make sense to implement 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 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] [Updated] (CAMEL-7939) Pluggable RedeliveryStrategy for RedeliveryErrorHandler
[ https://issues.apache.org/jira/browse/CAMEL-7939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Whiteside updated CAMEL-7939: --- Description: 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. was: 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, 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. Pluggable
[jira] [Commented] (CAMEL-7834) create a docker events endpoint
[ https://issues.apache.org/jira/browse/CAMEL-7834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14179558#comment-14179558 ] ASF GitHub Bot commented on CAMEL-7834: --- GitHub user sabre1041 opened a pull request: https://github.com/apache/camel/pull/306 CAMEL-7834 - Camel Docker Component Created a Docker component for Camel. Includes the functionality requested in [CAMEL-7834](https://issues.apache.org/jira/browse/CAMEL-7834) to consume events and includes the majority of the functionality as documented in the [Docker Remote API](https://docs.docker.com/reference/api/docker_remote_api/) You can merge this pull request into a Git repository by running: $ git pull https://github.com/sabre1041/camel CAMEL-7834 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/camel/pull/306.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 #306 commit 6f6ffe3c50a951d44edcac5e56c53831f541cfd2 Author: Andrew Block andy.bl...@gmail.com Date: 2014-10-22T04:11:09Z Add camel-docker component create a docker events endpoint --- Key: CAMEL-7834 URL: https://issues.apache.org/jira/browse/CAMEL-7834 Project: Camel Issue Type: New Feature Reporter: james strachan Docker provides a REST API to query events (for containers starting and stopping etc): https://docs.docker.com/reference/api/docker_remote_api_v1.14/#monitor-dockers-events it'd be nice to support a simple camel component to make it easier to consume docker events; with the events available as a JSON String or as a POJO -- This message was sent by Atlassian JIRA (v6.3.4#6332)
