camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Scott England-Sullivan <>
Subject Re: Turning CamelContexts into black boxes for reuse and composition (was Re: Abstracting Routes using Components
Date Wed, 23 Mar 2011 15:33:17 GMT
On Mar 1, 2011, at 1:39 AM, James Strachan wrote:

> On 11 February 2011 09:50, James Strachan <> wrote:
>> On 10 February 2011 20:13, Ashwin Karpe <> 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:
> 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.
> -- 
> James
> -------
> FuseSource
> Email:
> Web:
> Twitter: jstrachan
> Blog:
> Open Source Integration


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
H. 952.440.4568
C. 217.390.3058

View raw message