camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Talbut <>
Subject Re: How to get Exchange from a within a POJO without changing the interface?
Date Tue, 26 Jul 2011 06:56:15 GMT

Just read the 2.8.0 release notes, could I use MDC for this?
It's not currently enabled on my context, but I'll be using either Pax 
or logback so I can enable it.

If so, what excellent timing, thank you :)


On 26/07/2011 07:43, Jim Talbut wrote:
> Claus,
> That's useful, it would simplify my interface, but it wouldn't let me 
> leave it alone.
> My actual problem is that I need to be able to correlate the exchange 
> that called my POJO with exchanges generated by calls from my POJO.
> To do this I need to access the correlation ID (if it's been set) or 
> the exchange ID (if it hasn't) and then set them as headers.
> The class that actually calls the other routes uses ProducerTemplate 
> and I'm quite happy for that class to have Camel-specific code in it, 
> but the business logic class shouldn't need to know anything about the 
> correlation.
> I've been looking at writing a custom InflightRepository, but that 
> would have to map from thread ID, which won't work with the 
> asynchronous processing (nor will any other thread-local approach).
> If I try to set the correlation ID as a property on my busines logic 
> POJO I'll run into threading issues (it may be called concurrently).
> Thanks
> Jim
> On 26/07/2011 07:06, Claus Ibsen wrote:
>> On Tue, Jul 26, 2011 at 7:39 AM, Jim Talbut<>  
>> wrote:
>>> Hi,
>>> I have a POJO that benefits from having a non-Camel interface (it 
>>> means I
>>> can know that the interface matches that of a given web service).
>>> Internally this POJO needs to extract a couple of properties from the
>>> Exchange.
>>> Is there any way to get the "currently executing Exchange" without 
>>> adding it
>>> as a parameter to the POJO?
>>> Most useful for me would be either a static method or a method on the
>>> CamelContext, because they would allow me to move the Camel-specific
>>> processing into a separate bean.
>> On trunk I have improved the bean component, so you can bind the
>> parameters in the method name option.
>> .to"(bean:myBean?method=myMethod(${body}, ${},
>> ${}, 'This is a String'")
>> More details at:
>>> Thanks
>>> Jim

View raw message