camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Strachan <>
Subject Re: Abstracting Routes using Components
Date Thu, 03 Mar 2011 09:47:09 GMT
2011/3/1 Björn Bength <>:
> On Tue, 2011-03-01 at 09:10 +0000, James Strachan wrote:
>> On 28 January 2011 07:19, Willem Jiang <> wrote:
>> > On 1/28/11 4:36 AM, Mond Raymond wrote:
>> >>
>> >> Any more news on this?
>> >
>> > Ashwin already committed a camel-routebox component[1] into the Camel 2.6.0,
>> > and we will release it shortly.
>> >
>> > [1]
>> There's also a simpler to use implementation, using the CamelContext
>> as the 'component' and a simple naming convention:
> Hi,
> It's not possible to "connect" to another camel context via OSGi right,
> as they're not exposed like that?
> Or would it be advised to just use jms, nmr or vm in that case?
> Else I could possibly imagine some use cases for it.

Right now we've only really tested out the camel-context approach in a
pure Spring ApplicationContext. In principle the same idea could work
in OSGi too; though one added complication is inside a Spring
ApplicationContext we know that the CamelContext ids are unique so can
be used as a URI scheme. This isn't really the case when you look at
an entire OSGi container with many bundles being deployed.

You could use blueprint/spring-dm to lookup a CamelContext in OSGi and
create a smart proxy to it  and assign it an id - then use that id
with the camel-context code as shown in the Spring example above. Or
we could introduce a new component which looks up a CamelContext in
OSGi; though for now its probably simplest to just use the ServiceMix
Registry (the NMR) to refer to endpoints inside different OSGi

Twitter: jstrachan

Open Source Integration

View raw message