Hi Willem, thanks for your reply.
> I just checked the code on the trunk and can't exactly the change that you > made, can > provide a diff file for it ? Unfortunately I'm using sources from distribution via maven and can't access Apache SVN repo's because of restricted network, sorry. Therefore I added changed class to this mail hoping mailing list won't reject it. My change are between comment "BF-beging" and "BF-end". Please note that I'm using Camel 2.8.0 right now. I recognized that class "MethodCallExpression" was changed in trunk but I couldn't managed to get our test project running with 2.9-SNAPSHOUT until now (seems to contain more changes ...). As far as I understood Camel right I guess that - the splitter and associated expression for the "split bean" are created during "start up" of the route/camel context using the Camel Context. The original source creates an BeanHolder but this instance isn't used to create the BeanExpression. Instead "beanName" and "methodName" is used. As result BeanExpression.bean of this instance is empty. - Later, during running the route, this instance is needed but it seems that the "processor" doesn't own a reference to CamelContext therefore it uses the CamelContext from exchange instead. - If current exchange was (re-)created by an endpoint defined in server CamelContext all things are fine (example with jms). - If current exchange was created by an endpoint or producer in another CamelContext and not re-created, like with "vm" endpoint, than the bean can't be found. - If BeanExpression will be created using BeanHolder instance the problem is solved but I'm not sure whether it causes side effects or not. >> >> 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. > Sure, bean and method names are needed. But the topic is what is the right Camel/Spring Context to use for resolving it to a "real" reference. >> >> 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 > Imo it is a "systematic" question how much or which concrete info I can expect in my exchange/message. If that depends on "from" endpoint than it seems a little bit confusing to me. >> >> 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. > Try to ;-) could take some time because I'm a newbie on this area ... Best Regards Bernd
