camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ddewaele <>
Subject Re: Camel as an OSGI bundle - OSGI detection strategy
Date Fri, 16 Nov 2012 14:13:37 GMT
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).

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 ? 

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

At the moment I don't see how this can be handled in a proper way.

Donald Whytock wrote
> It's possible to do this using Camel without Spring also, but you'll
> need to listen for the publishing of the appropriate endpoint module
> services also.  Starting the Camel bundle isn't enough; some modules
> start after and register themselves with camel-core.

We're currently using Spring, and cannot remove this dependency.

One downside of not having the OSGI based Camel Context is the fact that the
TypeConverter package scanning doesn't work in OSGI. Other than that I
didn't see any issues so far. But I can imagine further down the line,
working with a non OSGI based Camel Context in an OSGI container will get us
into trouble.

View this message in context:
Sent from the Camel - Users mailing list archive at

View raw message