Freeman,
It would certainly make sense to lower the start level for the default installed features. I even think we should consider lowering it and 'hiding' them from the list, as they're just the system running (similar to what happens with the default Karaf bundles). This will make it easier for users to find their own bundles in the list that remains. For optionally installed features, we could also lower the start level on those, I guess -- given the limited impact of the bundle start level, I don't see a real issue there. For things like optional Camel components, that might make sense and it would solve some more problems during startup. Let's say we make the default features start level 40 and the optional ones start level 50 or something like that. However, it would be even better if we could also improve the way Camel looks up components by adding the possibility for a timeout when you're in an OSGi environment. The start level will fix most default Camel components, but as soon as someone start relying on a ComponentResolver being available in the registry, they can still run into timing issues. Adding the timeout would fix that bit and, if we provide some nice feedback on the console when we hit the timeout, we can also improve user experience when they're installing a route without installing the required component first (I've done this myself quite a few times, so there must be other folks out there that make the same mistake sometimes ;) ). Something like: ka...@root> osgi:install -s mvn:my.camel.project:bundle:1.0 Bundle id: 170 Waiting for component jcr: ka...@root> features:install camel-jcr Component jcr: found Regards, Gert Vanthienen ------------------------ FuseSource Web: http://fusesource.com Blog: http://gertvanthienen.blogspot.com/ On Mon, Jan 10, 2011 at 10:32 AM, Freeman Fang <[email protected]> wrote: > 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 > > -- > Freeman Fang > > ------------------------ > > FuseSource: http://fusesource.com > blog: http://freemanfang.blogspot.com > twitter: http://twitter.com/freemanfang > Apache Servicemix:http://servicemix.apache.org > Apache Cxf: http://cxf.apache.org > Apache Karaf: http://karaf.apache.org > Apache Felix: http://felix.apache.org > >
