L.S., I think adding support for pure OSGi deployments (no blueprint, spring, ...) might be an interesting addition to Camel as such. It's probably not that useful in the environment we typically have in mind (ESB, enterprise applications, ...) but for other use cases it may make perfect sense to be able to have a more lightweight approach available as well. Not entirely sure what the current OsgiCamelTracker is doing, but we could e.g. (just guessing what would be useful here, so feel free to amend/comment/...) build something that tracks RouteBuilder instances in the OSGi Service Registry and then creates CamelContexts to run those, with a service property to allow configuring the CamelContext instance to add the routes to?
Regards, Gert Vanthienen ------------------------ FuseSource Web: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ On Tue, Jun 21, 2011 at 4:38 PM, Donald Whytock <[email protected]> wrote: > Odd...I can see it there. I'll send it to you directly. > > Don > > On Tue, Jun 21, 2011 at 8:01 AM, Michael Furtak <[email protected]> wrote: >> Hi Don, >> >> I wasn't able to find OsgiCamelTracker.java attached to your message. >> >> Thanks, >> -Mike >> >> >> >> >> >> >> >> THIS MESSAGE IS INTENDED FOR THE USE OF THE PERSON TO WHOM IT IS ADDRESSED. >> IT MAY CONTAIN INFORMATION THAT IS PRIVILEGED, CONFIDENTIAL AND EXEMPT FROM >> DISCLOSURE UNDER APPLICABLE LAW. If you are not the intended recipient, your >> use of this message for any purpose is strictly prohibited. If you have >> received this communication in error, please delete the message and notify >> the sender so that we may correct our records. >> >> -----Original Message----- >> >> >> >> From: Donald Whytock [mailto:[email protected]] >> Sent: Monday, June 20, 2011 4:45 PM >> To: [email protected] >> Subject: Re: Camel under OSGi without Spring et al. >> >> 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 >> >> >
