I'm sorry you're right. Our 20+ routes do have matchOnUriPrefix such as:
http://0.0.0.0:8080/...?matchUriOnPrefix=true"; />
In my original scenario but with this additional change what would happen?
eg:
route1:
http://0.0.0.0:8080/?matchOnUriPrefix=true"/>
...
route2:
http://0.0.0.0:8080/applic
PGP cannot be processed unless the memory exists. I don't know of an
in-stream component like you are talking about. You could write one with
bouncy castle or make a code addition to the existing components to read
from a stream. Then you could submit that back to the community. ;)
On Friday, Dece
In that case you are going about it wrong. Camel has this support built in
for you. If the route is declared to be transacted with
.transacted(myRequirdPolicy) then camel will handle that all for you with
that one line. Put the transacted line right after your exception handleing
and before the mai
Thanks for replying. Here is my usecase:
consume a message from the queue. Do some transformation on the messge.
Then, persist the transformed message to datastore.
Once, transformed message is written to datastore, send ack. Reason i want
to send ack later is, in case my application goes down pos
I don't think the question is quite clear. In JMS you can only consume a
message off a queue once. You can't consume it and leave it on the queue.
Why do want to not ack the message? Queues are like throwing candy into a
room of kindergarten children. All will scramble for the candy but each
piece
Typically you would use a recipient list if there are potentially more than
one receiver or if the receiver is not known at compile time. So if you
have a record where the receiver is calculated off some data from another
system you would use a recipient list. If you have known routing situation
at
Hi,
Any help here will be highly appreciated.
On Fri, Dec 20, 2013 at 9:55 AM, Tarun Kumar wrote:
> I am using polling consumer.
>
> from("timer://foo?period=5000").bean(cool, "someBusinessLogic");
>
> public static class MyCoolBean {
>
> private ConsumerTemplate consumer;
>
>public void
The requirement seems a bit odd as the receiver header could be derived at
the consumer, anyway you may be able to access the
Exchange.RECIPIENT_LIST_ENDPOINT property or perhaps try setting
onPrepareRef with a custom processor to figure out the header.
Henrique Viecili
On 20 December 2013 19:13
