Re: Problem with maintaining a JMS subscription after waking from sleep
I was using Camel 2.2.0 so I've now upgraded to 2.3.0 in the hope that the problem may go away. My other thought is to upgrade the camel-activemq component. I noticed that I'm using activemq-camel:5.2.0 as per the doco. and that this brings in activemq-core:5.2.0 and activemq-pool:5.2.0. This is obviously behind the current release of AMQ which is 5.3.2, so I'm wondering if there have been fixes around that. If my Camel upgrade doesn't look to have effected the problem then I'll bring in activemq-*:5.3.2 and see if that makes a difference. Any other pointers greatly appreciated of course. -- View this message in context: http://camel.465427.n5.nabble.com/Problem-with-maintaining-a-JMS-subscription-after-waking-from-sleep-tp510193p510288.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Problem with maintaining a JMS subscription after waking from sleep
Hi, I think it should be OK to use Camel 2.3.0 with ActiveMQ 5.3.x, as we ran the development tests of Camel with ActiveMQ 5.3.x. Willem huntc wrote: I was using Camel 2.2.0 so I've now upgraded to 2.3.0 in the hope that the problem may go away. My other thought is to upgrade the camel-activemq component. I noticed that I'm using activemq-camel:5.2.0 as per the doco. and that this brings in activemq-core:5.2.0 and activemq-pool:5.2.0. This is obviously behind the current release of AMQ which is 5.3.2, so I'm wondering if there have been fixes around that. If my Camel upgrade doesn't look to have effected the problem then I'll bring in activemq-*:5.3.2 and see if that makes a difference. Any other pointers greatly appreciated of course.
Re: Reading Binary Files and Passing to HTTP Component
https://issues.apache.org/activemq/browse/CAMEL-2833 Patch included. On Sat, Jun 19, 2010 at 2:46 AM, Claus Ibsen claus.ib...@gmail.com wrote: On Sat, Jun 19, 2010 at 9:58 AM, Willem Jiang willem.ji...@gmail.com wrote: Hi， I don't think current camel-http support the multipart/form-data out of box, as the HttpProducer will try to turn message body into an input stream if the http method is POST. Ah yeah we should most likely support FileRequestEntity and InputStreamRequestEntity out of the box. We should most likely do something like If body is file based - FileRequestEntity If body is String based - StringRequestEntity (only check body instanceof String, to avoid type converting as anything can be converted into String) Else fallback to the InputStreamRequestEntity I wonder for the file based that people may want to read the content of the file and send that instead? For that they can use the .convertBodyTo(String.class) in the DSL before hitting the to http. But we could also offer an option to set which request entity preferred, just as we can do that with JMS.
