Getting fabrics to honor bundle start-level

[javidel...@gmail.com]

All,

We have some features that work within Karaf 2.2.8.  We have modified the start-levels for the bundles so that the services are started in the correct order.  When I include our feature in a fabric profile, all the bundles get the same start-level (60) and many of the bundles time-out waiting for other bundles to initialize. 

Is there a way to get the container to honor the start-levels of the features it's running? 

-Javier

[Guillaume Nodet]

Not at the moment.

Can I ask why you need to rely on the bundle start level ? This is usually a bad idea.  Most of the time, having properly defined service dependencies is a way better way to solve bundle start ordering.

--
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
FuseSource, Integration everywhere
http://fusesource.com

[Javier]

Guillaume,

Thanks for your reply.

As far as why we're using start-levels, we've got an application with tiers in it.  For example, we publish an interface that a component can implement in a bundle which we then use in other parts of the product.  We also have a bundle that that keeps track of all the bundles that implement the interface (a registry).  Our CXF REST bundle then uses the service exported by the Registry bundle so we can quickly see the components that are available in the system of the interface. We have several scenarios like this in our code, so the number of Registry/REST bundle dependencies is quite large.  Then we also have some components that manage user configurations managed via REST Endpoints which adds to the run-time dependency tree.  This creates a REST->Manager->Persistence dependency tree as well.

Under Karaf, we found that having the Persistence bundles start first, then Registry/Managers, and finally the REST layer gave us better results with preventing dead-locks at startup due to a configuration that created unforeseen run-time dependencies.

Getting back to my problem, like you suggested, I started refactoring our feature.  Now I've got one feature with all of our 3rd party dependencies (foundation), apis feature (depends on foundation), then a basic services feature (depends on apis)--which has bundles with blueprint configurations that export services for use by other bundles in the system.

And what I'm finding is that one of our bundles (which exports a service used by many other bundles) in the basic services feature cannot get a reference to one of the other services we've exported from a different bundle (regardless if the service we're trying to get a reference to is in the same feature or in another feature that I add as a dependency).  I can't figure out what's going on.  I've switched from blueprint configuration to a ServiceTracker and neither gets me the service I need.  I created a dummy bundle that instantiates one bean that gets a reference to the service in question and it initializes just fine with Blueprint, but the original one just will not get the reference to the same service (very weird).  Since many of the other bundles in our product depend on this one bundle that doesn't start up, the bulk of our bundles fail after timing out during the GracePeriod.

Mind you, the persistence layer is loading fine and that has a similar approach where one bundle exports some basic configuration info which is then used by specific implementations for saving configurations to disk.  So some bundles do export services that are successfully imported by other bundles.

I've already trimmed the list of bundles in the basic services feature to the bare minimum to get the failing bundle started.  The bundle starts just fine if I remove the blueprint reference to the service in question and replace it with a ServiceTracker.  But I never see the log statement that I added to the bundle when my addingService method is called with a reference to the service in question.  So although the bundle starts, I'm not getting a reference to the service I need.  I'm running out of ideas on trying to figure out why that one bundle can't get a reference, so if anyone has an idea on how to further debug this, I'd greatly appreciate it.

Thanks for your time.

On Monday, August 13, 2012 4:02:01 PM UTC-7, gnodet wrote:

Not at the moment.

Can I ask why you need to rely on the bundle start level ? This is usually a bad idea.  Most of the time, having properly defined service dependencies is a way better way to solve bundle start ordering.

[Javier]

It seems like the problem was with the pom.xml for the one bundle that couldn't get the service.  After reviewing the pom.xml file for the bundles in question, I noticed there were no instructions configured for the maven-bnd-plugin for the bundle that could not get a reference to the service.  After adding a configuration with instructions for Bundle-SymboleName,Export-Package, and Private-Package the fabric was able to load all of my bundles.