The ASF mailinglists tend to strip of attachments... Bye, Norman
2011/6/21 Donald Whytock <[email protected]>: > 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 >> >> >
