I get multiple routes in OSGi by having a service that provides a singleton CamelContext. Bundles consume the same CamelContext and create on it whatever routes they need.
Though I do this in Java, not Spring, so this might not be what you're looking for. Don On Tue, May 3, 2011 at 5:18 PM, Klug, Johannes <[email protected]> wrote: > > I'm having some troubles with this as well. Could someone enlighten us what > the best way would be to get multiple routes into a single OSGi application? > > > -----Original Message----- > From: Mark Doyle [mailto:[email protected]] > Sent: Sun 5/1/2011 10:02 PM > To: [email protected] > Subject: Problem designing a camel route for an OSGi system. > > I have the spring file below. It simply creates a couple of beans > which are used in a camel route. The camel route is obviously > configured in the context section. One of the beans is actually an > OSGi service (id camelParameterProvider) which means it's used by > multiple service consumer bundles (In this case there are many eclipse > views using it to get data). Unfortunately this means all service > consumers share the same bean which has the same route! (I assume the > same camel context?) This would be fine but I want to filter the > incoming data using the parameterFilterer bean. The filtering part > works fine except that all the views are sharing the same service > provider bean so when one filters the route all the other consumers > only receive the filtered messages too. > > One way I explored to solve this was to use the bundle scope for the > bean. Unfortunately the camel route references only a bean uri (the > "to" part of the route) so no messages are routed. I guess camel has > no way to know which instance of the bean to route to (and why would > it). > > Is this a symptom of a bad design or is there a way around this. > Perhaps creating a bean that provides the OGSi service AND is a > routebuilder then trying to use that with bundle or prototype scope... > > P.S. I'm not sure if this is a Camel, Spring, or OSGi issue! :) > > I created a diagram here that may explain the overall view better: > http://dl.dropbox.com/u/10007025/hbird/pictures/hummingbird%20gui%20parameter%20retrieval.png > > Spring file: > > <!-- Acts as a dynamic filter --> > <bean id="parameterFilterer" > > class="org.hbird.rcpgui.camelparameterprovider.ParameterNameFilterer"> > </bean> > > <!-- > Create a camel parameter provider bean for use by the > services-context.xml > (Spring DM). > --> > <bean id="camelParameterProvider" > > class="org.hbird.rcpgui.camelparameterprovider.CamelParameterProvider" > autowire="autodetect"> > </bean> > > <!-- Create a jms endpoint for the route used by this provider --> > <bean id="jms" class="org.apache.camel.component.jms.JmsComponent"> > snip! > </bean> > > <camelContext id="camelContextBean" > xmlns="http://camel.apache.org/schema/spring";> > <route id="fromJmsProcessedParametersOut" autoStartup="false"> > <from uri="jms:topic:processedParametersOut" /> > <camel:filter> > <camel:method > bean="parameterFilterer"></camel:method> > <to > uri="bean:camelParameterProvider?method=parameterIn" /> > </camel:filter> > </route> > </camelContext> > > > > > Think green - keep it on the screen. > > This e-mail and any attachment is for authorised use by the intended > recipient(s) only. It may contain proprietary material, confidential > information and/or be subject to legal privilege. It should not be copied, > disclosed to, retained or used by, any other party. If you are not an > intended recipient then please promptly delete this e-mail and any attachment > and all copies and inform the sender. Thank you. > >
