L.S.,
Exactly -- start level only controls when a bundle get started, but doesn't say anything about the services it provides or requires. As Blueprint and Spring contexts get started asynchronously, services are added to the service registry and become available for other bundles to use. Once again, I do agree we should try to get the bundle start level configured properly to make a good distinction between the default bundles and user applications being deployed later on. This might prevent a few of the issues people are running into, but in general bundles and their services should get started by the framework as their dependencies become available, so that's what we should be trying to accomplish. In the original Camel problem, the real solution is in allowing the component registry to wait for a moment while components are becoming available -- that's what we need to leverage the benefits of the dynamic nature of OSGi. A similar solution can be found in a lot of OSGi technologies: blueprint will wait for services and namespace handlers to become available, FileInstall will retry to deploy a previously unknown file type as soon as new deployment options become available, ... I'm not sure what the exact problem is that ODE is facing, but if you could give us some extra information there, I'm pretty sure we can come up with an elegant solution for that as well. It's definitely not a unique problem, so there are a lot of examples around in projects like Aries and Felix that we could 'borrow' from. Regards, Gert Vanthienen ------------------------ FuseSource Web: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ On Mon, Jan 10, 2011 at 5:55 PM, Kurt Westerfeld <[email protected]> wrote: > There is also the case to handle where a "system" bundle is started, and a > bundle tracker or something similar does an async start on a separate thread. > Witness the extender bundle activation models--lots of threads starting > asynchronously. > > This all OK, but fast-forward to the situation where something like Camel or > ODE is providing infrastructure services that watch for user bundles later. > The startup of Camel, I know nothing about, but in ODE's case it's starting a > bunch of internal services, all the while the bundle is "started". Now, this > may be a bug in the ODE code, but I don't think it's unique. I don't know > what the right answer is here but I thought I'd point out that just getting a > bundle to "started" state doesn't seem to always be the final answer. > >>>> Daniel Kulp <[email protected]> 1/10/2011 11:46 AM >>> > > I'm definitely in support of this as well. I'd actually suggest taking it a > bit furthur and trying to define some sort of hiearchy of levels and put > things in more apprioriate places. > > For example, it's definitely in the best interest of everything to get most of > the "api" bundles started up ASAP. Otherwise, you can easily get into > situations where some bundles use the "system" versions and othere use the > bundle version and such. Thus, it might be good to say level 20 is for all > the API jars and 25 for the "impls" or similar, just to make sure the API jars > are available real early. JAXB and JAX-WS API jars are really affected by > this pretty badly, especially with the 2.2 versions being a bit incompatible > with the version in the JDK. > > Dan > > > On Monday 10 January 2011 11:01:21 am Kurt Westerfeld wrote: >> I ran into a similar issue with system bundles being partially started with >> Apache ODE and related startup issues. It was my suggestion then to start >> system bundles < 60 and user bundles >60. Would this apply to all bundles >> that are supplied with features on SMX (like ODE), or just select ones? >> I'm highly in favor of this, btw. >> >> >>> Freeman Fang <[email protected]> 1/10/2011 4:32 AM >>> >> >> Hi, >> >> How about we specify start level for camel feature bundles less than >> 60, so that when restart servicemix, the camel related bundles always >> get started before end users bundle, this can avoid lots of asyn >> issues customer may encounter, such as camel component not available >> yet when end users bundle get started. >> >> Actually this discussion initially from fuse forum[1], and I'm not >> very sure heavily depend on bundle start level is a good practice in >> OSGi world, but I must admit that in servicemix camel should be >> considered as a part of the framework, so give higher priority for >> camel bundles seems OK. >> Btw, karaf features already support specify start level, so it should >> be doable in Servicemix to do it. >> >> I'd like hear more voice, thoughts? >> >> [1]http://fusesource.com/forums/thread.jspa?threadID=2493 >> >> TIA >> Freeman > > -- > Daniel Kulp > [email protected] > http://dankulp.com/blog >
