On Mar 1, 2011, at 1:39 AM, James Strachan wrote:
> On 11 February 2011 09:50, James Strachan <ja...@fusesource.com> wrote:
>> On 10 February 2011 20:13, Ashwin Karpe <aka...@fusesource.com> wrote:
>>>
>>> Hi James,
>>>
>>> I like the approach. It certainly replaces the need to have a Strategy and
>>> eliminates the need to inject a context into a component.
>>
>> Thanks!
>>
>> Am sure there's uses for the RouteBox approach when folks want to do
>> different things; though my gut feel was just to use regular Camel
>> endpoints as the 'API' to the black boxed components; then you can use
>> the regular Camel routing engine as the 'strategy' for consuming from
>> those endpoints and doing Content Based Routing or whatever.
>>
>>
>>> If everyone agrees, I will be happy to develop this capability along these
>>> lines and open it up for review and comment.
>>
>> Great stuff thanks! BTW before I sent the previous email I'd checked
>> in an implementation and a number of test cases to check it worked;
>> using concise or verbose URIs using the Java DSL. Though we need more
>> testing of using this concept more with Spring; we might have a few
>> gremlins when working with multiple contexts and using some of the
>> injection & annotation features; which up to now have tended to assume
>> only a single CamelContext etc.
>
> FWIW I've just committed a test case showing this working in Spring
> XML now. See SpringDslContextComponentTest in camel-context.
>
> There was a lifecycle issue with CamelBeanPostProcessor which was
> eagerly resolving references to CamelContext - causing the
> CamelContext to be started eagerly which if you use multiple
> CamelContexts in a single XML file was causing lifecycle issues (and
> breaking the behaviour of depends-on) - which has now been made lazy
> to avoid this issue.
>
> Here's the test case:
> https://github.com/apache/camel/blob/trunk/components/camel-context/src/test/java/org/apache/camel/component/context/SpringDslContextComponentTest.java
>
> notice how we inject the MockEndpoint and the ProducerTemplate from
> the 'tester' CamelContext.
>
> Then here's the Spring XML; we route from tester's direct:start to the
> accounts CamelContext and consume from the output on the accounts
> direct:invoice endpoint.
>
> https://github.com/apache/camel/blob/trunk/components/camel-context/src/test/resources/org/apache/camel/component/context/SpringDslContextComponentTest-context.xml
>
> --
> James
> -------
> FuseSource
> Email: ja...@fusesource.com
> Web: http://fusesource.com
> Twitter: jstrachan
> Blog: http://macstrac.blogspot.com/
>
> Open Source Integration
All,
First off, this is exactly what I was hoping for. Kudos to all.
To bring this back around to the original suggestion, there was concern over
the CamelContext being too heavy.
{Claus Isben: Re: Abstracting Routes using Components: Oct 27th, 2010}
…
Having a nested CamelContext, we would maybe have to strip it down
from some features to keep it lighter (loading type converters, JMX
management, event notification, OSGi complexity, lifecycle etc.).
...
I am assuming there is still a potential issue here or maybe not. If there is
concern, is it something that will be addressed in the future and/or is there
guidance on how to 'slim' down a nested CamelContext?
Scott England-Sullivan
twitter: sully6768
sully6...@yahoo.com
H. 952.440.4568
C. 217.390.3058
