2011/3/1 Björn Bength <[email protected]>: > On Tue, 2011-03-01 at 09:10 +0000, James Strachan wrote: >> On 28 January 2011 07:19, Willem Jiang <[email protected]> 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]https://cwiki.apache.org/CAMEL/routebox.html >> >> There's also a simpler to use implementation, using the CamelContext >> as the 'component' and a simple naming convention: >> >> http://camel.apache.org/context.html >> > > > 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 bundles. -- James ------- FuseSource Email: [email protected] Web: http://fusesource.com Twitter: jstrachan Blog: http://macstrac.blogspot.com/ Open Source Integration
