camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Talbut <jtal...@spudsoft.co.uk>
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 :)

Jim

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<jtalbut@spudsoft.co.uk>  
>> 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}, ${header.foo},
>> ${header.bar}, 'This is a String'")
>>
>> More details at:
>> http://camel.apache.org/bean-binding.html
>>
>>
>>
>>> Thanks
>>>
>>> Jim
>>>
>>
>>
>


Mime
View raw message