Menu
My team are trying to develop a new system based on OSGi, and now we have more than 50 bundles and counting. The problem is, there is dependency between bundles. For example, when bundle A startup, it will register a service to OSGi, and when bundle B startup, it will use that service. Therefore I need bundle A startup earlier than bundle B. To make this happen, I set the start level of bundle A less than bundle B.
We tried to use ServiceTracker to avoid setting start levels, but when the services count growing up, it become difficult to manage and to understand the whole system.
However, I found this article on the internet: OSGi and Start Levels. I'm not sure with two sentences in it:
- Start order within the start level is indeterminate!
- On the whole, when working with start levels, never depend on start order. Think about start levels as a management issue, not a development time issue.
Does it mean that start level will not decide the start order? Then when should I use it?
Is it reasonable to use different Start Levels to manage the dependencies between OSGi bundles?
It is possible to make all the bundles being a dynamic module(use ServiceTracker to track all the services it use), but it takes more time and demand senior developers, and the system become difficult to debug.
465
1): Module Layer - it is responsible for managing dependencies between bundles and for class loading (See Bundles Section);
The Start Level API provides the following functions: Controls the beginning start level of the OSGi Framework. Is used to modify the active start level of the Framework. Can be used to assign a specific start level to a bundle. Can set the initial start level for newly installed bundles.
All MOTECH modules run in a Felix OSGi framework instance embedded within the platform war. Because of this all libraries you make use of in your module should be packaged as actual OSGi bundles.
jar,. The Bundle-ClassPath header defines a comma-separated list of JAR file path names or directories (inside the bundle) containing classes and resources. The full stop ( '. ' \u002E ) specifies the root directory of the bundle's JAR.
My answer is similar to Bertrand: you should consider using a higher-level component-based abstraction for your solution: SCR, iPOJO, Blueprint, etc.
Using start levels to control dependencies is a little like using thread priorities in Java to fix race conditions. Sure, you might make things work, sort of, for a while, but you'll go insane in the process--and you'll eventually lose anyway.
Start levels are useful. The canonical example is if you need to display a splash screen while starting your OSGi-based GUI application by putting the code for it in a bundle. Without start levels there's no way to ensure the splash screen would end up displayed when it's supposed to be, but using start levels this becomes trivial.
That said, I've used start levels to resolve dependency ordering bugs found in third-party bundles (e.g., Spring), though this didn't involve service ordering but assumptions about finding resources (with Spring, an XSD for the Spring Integration custom namespace).
186
Using start levels to manage dependencies between services is a bad idea - the Services Component Runtime (SCR) is a much better way of managing that, and if done right will take care of all the dependencies, startup order, restarting components when their required services are restarted, etc.
If you're using Maven, the Apache Felix SCR plugin ( http://felix.apache.org/site/scr-annotations.html ) makes it easy to create SCR-managed services using just a few Java annotations. Apache Sling's code ( http://sling.apache.org ) is full of examples using this.
37
A good summary about the start level/dependency issue that explains why you have to avoid to define dependencies between your bundles with start levels.
http://wiki.osgi.org/wiki/Avoid_Start_Order_Dependencies
38
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
