OsgiCamelTracker.java (attached) is a work in progress. There's a reference to ContextUtil; that's the service class that supplies the CamelContext singleton.
Use it by subclassing it and implementing methods start() and stop(). Call setBundleContext(bundleContext) first, then startTracking(). OsgiCamelTracker.startTracking() accepts no parameters, a single String, or a Collection<String>. The strings are the names of components that you need. It'll track instances of ComponentResolver, maintaining a list of what components are available and what components are still needed. When all the components you need are available, it'll call start(); when any of the components cease to be available, it'll call stop(). If you don't supply component names, it'll react to camel-core itself becoming active, which is all you need for core components like mock, bean and file. Use routeId(<name>) in your route definitions. Use camelcontext.startRoute(<name>) from the OsgiCamelTracker.start(); use camelcontext.stopRoute(<name>) from the OsgiCamelTracker.stop(). Be advised, you'll need to use a singleton CamelContext if you're using SEDA queues, because SEDA queues are local to a CamelContext instance. A route that consumes from a SEDA queue from one CamelContext instance won't see anything produced to a SEDA queue from a different CamelContext instance. For OsgiDefaultCamelContext... > On Mon, Jun 20, 2011 at 3:31 PM, Michael Furtak <[email protected]> wrote: >> I did come across mention of this in my troubleshooting exploration. It >> seems to be part of a bundle called camel-core-osgi, is that right? I don't >> think I have it in my 2.7.2 distribution. Is it something I need to bundle >> myself? I also saw mention of it being private to the Spring bundle, which >> is what prompted my discussion about not wanting to bring in Spring. org.apache.camel.core.osgi is in camel-blueprint.jar. I split it out into its own .jar so as to not worry about the Blueprint dependencies. You'll need to modify the manifest, or make your own. Don
