camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Donald Whytock <>
Subject Re: Camel as an OSGI bundle - OSGI detection strategy
Date Fri, 16 Nov 2012 18:17:21 GMT
On Fri, Nov 16, 2012 at 9:13 AM, ddewaele <> wrote:
> Donald Whytock wrote
>> The preferred way in OSGI is having a BundleListener listen for a
>> STARTED event.  You'd put this in the bundles that are trying to
>> create routes.
> As soon as my bundle containing the camel route is started, the Spring OSGI
> extender kicks in, and immediately refreshes my spring context (resulting in
> the creation of the non-osgi camel context if the camel-spring bundle wasn't
> started). I don't see a hook where I can influence this behavior.
> Putting the listener in my bundle means that the bundle start event for
> camel-spring will be delivered when my bundle is starting (=too late).

This depends on how you're starting your routes.  If you're starting
them with Spring XML, I personally can't help you, but others might.
But if you're starting them programatically, you can have the code
that starts the routes be triggered by a BundleListener event.  Your
bundle can start, and defer starting your routes until the event is

> Donald Whytock wrote
>> If you have a number of bundles dependent in this way, you might want
>> to create a bundle that does the listening for the camel-spring bundle
>> and publishes a service the other bundles submit custom listeners to.
>> That reduces, or at least centralizes, your dependence on extenal
>> events.
> Do you have some sample code or a pointer to some documentation regarding
> this approach ?

Sorry, my project site was recently hacked.  I'll have to find my
archives.  Ping me in a week if I haven't responded, please.

> Most of the camel osgi samples are being run on equinox / karaf , where
> there is some level of control of how and when bundles are started (as they
> are started from the console).
> In the case of an EBA file, it's the container that loads them so there is
> lesser control (and these bundle start order dependencies should be avoided
> offcourse).

Bundle start order dependence is hard to avoid in osgi.  How I
understood it is that if you're dependent on an external bundle or
service you need to be sensitive to whether or not the dependency is
there or if it suddenly goes away.  I may have taken this a bit far in
some of my own code, but I got involved in OSGI and Apache Felix
specifically to give myself hot-swap capacity.


View raw message