camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Willem Jiang <willem.ji...@gmail.com>
Subject Re: Resolving beans in multi Camel Context use cases
Date Wed, 12 Oct 2011 03:11:49 GMT

On Tue Oct 11 23:20:05 2011, Bernd Fischer wrote:
> Hi all together,
>
> during playing around with Camel I found an use case for which I like
> to ask the "experts" for some advice.
>
> I'm using Camel 2.8.0 with spring 3.0.5 on java 1.6 in a multi Camel
> Context unit test scenario (one for simulating client and one for
> server).
>
> For uri's like
>
> <to uri="bean:processor?method=process"/>
>
> Camel usually resolves beans during creation of endpoints. This way
> Camel Context from endpoint, which points to Spring application
> context containing bean definition, is used. This works well.
>
> The splitter component can use a "split method" with similar "syntax".
>
>        <split>
>          <method bean   ="stringLineSplitter" method="split"/>
>          <log    message="before sending: ${body}"/>
>          <inOut  uri    ="vm:route04"/>
>          <log    message="after sending"/>
>        </split>
>
> It seems that this "split bean" is resolved using Camel Context from exchange.
>
> If I send an exchange using client Camel Context, please remember I'm
> using two Camel Contexts, to a route defined in server Camel Context
> using in-memory transport like "direct" or "vm"
>
>      <route id="route02" trace="false" streamCache="false">
>        <from uri="vm:route02"/>
>        <split>
>          <method bean   ="stringLineSplitter" method="split"/>
>          <log    message="before sending: ${body}"/>
>          <inOut  uri    ="vm:route04"/>
>          <log    message="after sending"/>
>        </split>
>        <to uri="mock:route02"/>
>      </route>
>
> the test fails with "Cannot find class: stringLineSplitter" thrown
> from a class "ObjectHelper". If I understood Camel right it fails
> because it tries to resolve this bean based on client Camel Context
> which is still set at the exchange send from client to server but
> doesn't contain the bean.
>
> If I send an exchange using same client Camel Context to a route in
> server Camel Context involving "external" components like "jms"
> (ActiveMQ)
>
>      <route id="route03" trace="false" streamCache="false">
>        <from uri="jms:queue:route03"/>
>        <split>
>          <method bean   ="stringLineSplitter" method="split"/>
>          <log    message="before sending: ${body}"/>
>          <inOut  uri    ="vm:route04"/>
>          <log    message="after sending"/>
>        </split>
>        <to uri="mock:route03"/>
>      </route>
>
> the test passed successfully. It seems that "jms" component creates a
> new exchange but "vm" reuses the one from internal queue.
>
> After diving into the code I found a place to adjust this behavior.
> Changing one line in the else-clause of
>
> class org.apache.camel.model.language.MethodCallExpression
>
> method
>
> createExpression( CamelContext camelContext ) : Expression
>
> from
>
> answer = new BeanExpression( ref1, getMethod() );
>
> to
>
> answer = new BeanExpression( this.instance, getMethod() );
>
> did the trick (means: now all my tests passed successfully).
> In the code lines before the bean holder was already created but in
> original version not used.

I just checked the code on the trunk and can't exactly the change that 
you made, can provide a diff file for it ?

>
> Now my questions:
>
> 1. Is it right to expect that both use cases should behave similar?
I'm not sure how can you get the bean instance without looking up by 
using the reference name.
> 2. Shouldn't every component create a new exchange during
> receiving/consuming, minimally re-set Camel Context if it crosses
> borders?
I think we can reset the camel context on the exchange when the VM 
endpoint consume it, and it would not change
> 3, Is the proposed change correct or will it produce (unwanted) side effects?
> 4. If change is ok could it be part of Camel?
Could you create a JIRA and submit a simple testcase with your patch?
It will be helpful for us to put this fix into the feature release of Camel.

>
> Any help/comment/hint are highly welcome.
>
> Best Regards
> Bernd
>


-- 
Willem
----------------------------------
FuseSource
Web: http://www.fusesource.com
Blog:    http://willemjiang.blogspot.com (English)
          http://jnn.javaeye.com (Chinese)
Twitter: willemjiang
Weibo: willemjiang

Mime
View raw message