Have you tried externalizing the onCompletion(), such as putting this as a
separate statement above your route and below the onException()
onCompletion()
.log("parallel processing is done")
.setBody(constant(null)).to("direct:c");
Mary
Mary Cochran
Red Hat Consulting
mcoch...@redhat.com
Was your previous environment still a Spring environment? Could you share
your route and/or camel-context config?
Mary
Mary Cochran
Red Hat Consulting
mcoch...@redhat.com
(419) 543-0531
On Mon, Oct 9, 2017 at 3:31 PM, Raymond de Hond
wrote:
> Hi,
>
> I try to create a simple contract first w
I'm aware, and have no idea why Servicemix is holding on to the 2.16 line
with Camel. Its frustrating but I'm stuck with Servicemix.
On Wed, Oct 18, 2017 at 10:49 AM, Claus Ibsen wrote:
> Hi
>
> I am not sure, as Camel 2.16 is EOL. Maybe you would mind looking at
> the latest code and find out
Dear list users,
I am checking my options on how to parse fixed length format data where
total lenth is variable, because blank chars from end of last field are
being removed. Therefore I am looking for something like
ignoreMissingTrailingChars. Example:
Lets have field pos 1 length 1 and field 2
You can use event notifier where you can then listen for the exchange
complete event and do your custom logic there, then its global.
Or an alternative could be to use a RoutePolicyFactory that can add a
RoutePolicy to all your routes, where you have an onExchangeDone
callback. Mind to read its ja
Hi
I am not sure, as Camel 2.16 is EOL. Maybe you would mind looking at
the latest code and find out what it does.
On Tue, Oct 17, 2017 at 9:15 PM, Mark wrote:
> I'm using Camel 2.16, which is a part of Servicemix 6.1.1. I'm using the
> camel-websocket component and I'm trying to figure out h
Hi
Using handled=false on doTry is deprecated and you should not do that.
In the Java DSL you will notice its deprecated.
And yes its the expected behaviour as its deprecated and you are
explicit doing a try .. catch style.
Use onException instead as it can log the message history / stacktrace e
Hi,
I discovered that, in fact, the exception is not handled (just as I want it
to be), but the log doesn't record either the stack trace, nor the Message
History.
Any idea why this would happen? Is it the normal behavior? Can I change it?
Thanks!
Laurentiu
On Tue, Oct 17, 2017 at 4:35 PM, Laure