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
