Working with different service levels would work, but it would mean every bundle that's dependent on Camel, or dependent on bundles that are dependent on Camel, would need to be at the higher service level. The Felix and OSGi groups seem to recommend against this approach; they advocate being able to track bundles regardless of service level.
This is especially true since bundles can be swapped out at runtime. While camel-core itself probably won't be, I could see someone testing a new component and swapping in new versions of it over and over. A bundle dependent on that particular component would need to know when the component was live. Service level wouldn't provide that. But all components go through TypeConverterLoader, right? So before I'm doing anything with an OsgiCamelContext I need to know that the TypeConverterLoader service is live. And since that's a condition specific to Osgi, it seems like the responsibility for tracking TypeConverterLoader should be in camel-core-osgi. Perhaps tracked by, yes, an OsgiDefaultCamelContextFactory service. Though this raises an interesting question: Given TypeConverterLoader is active, should there be some sort of ComponentTracker, tied to the CamelContext, so that apps dependent on a component can know whether or not to run? On Tue, Apr 5, 2011 at 10:47 PM, Willem Jiang <[email protected]> wrote: > On 4/2/11 6:33 AM, Donald Whytock wrote: >> >> I was able to build an app with OsgiDefaultCamelContext, but I had to >> add a ServiceTracker to wait for >> org.apache.camel.spi.TypeConverterLoader to be registered. Before I >> did that, my bundles were trying to create SEDA queues before >> camel-core had finished loading. > > If you are setting your application system level great then the camel-core, > you may work around that kind of issue. > >> >> If camel-core-osgi is going to be split into a separate bundle in 2.8, >> I'd like to suggest adding a couple things: >> >> - A service that supplies instances of OsgiDefaultCamelContext on >> demand. This gives applications a service to track before attempting >> camel operations. > > Do you mean that you want an service which works as a > OsgiDefaultCamelContext factory ? > >> >> - An activator that does whatever service/bundle tracking is needed >> before registering the service. This isolates applications from >> camel-core workings. > > As there are lots of camel-components which will be loaded from different > bundle, even you can use the service tracker to wait the > TypeConverterLoader, you can not make sure > > A better solution is the application bundle and camel component feature > bundle started with different system level. > > May this blog[1] can give you some inspiration. > >> >> Thanks... >> >> Don >> > > [1]http://fernandoribeiro.eti.br/2011/01/10/issues-with-routes-in-progress-fuse-4-2/ > > Willem > > -- > Willem > ---------------------------------- > FuseSource > Web: http://www.fusesource.com > Blog: http://willemjiang.blogspot.com (English) > http://jnn.javaeye.com (Chinese) > Twitter: willemjiang > > Connect at CamelOne May 24-26 > The Open Source Integration Conference > http://camelone.com >
