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 offcourse). 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: http://camel.465427.n5.nabble.com/Camel-as-an-OSGI-bundle-OSGI-detection-strategy-tp5722787p5722864.html Sent from the Camel - Users mailing list archive at Nabble.com.
