Page History

...

There are two ways to set these system properties. The first way is using the standard -D<property>=<value> syntax when executing java or if you are using Felix' standard Main.java launcher, you can put the system properties into the conf/system.properties file so that they get set automatically each time you execute Felix.

Should a service provider/consumer bundle be packaged with its service API packages?

There is no easy answer to this question and it largely depends on the specific usage scenario. The OSGi specification had originally suggested that it was good practice to embed service API packages in the service provider bundle. In this case in OSGi R4, the service provider should both export and import the service API packages, which was the default for previous versions of the OSGi specification.

The OSGi specification never had an explicit stance on whether or not a consumer bundle should embed its dependent service API packages; although, it would not appear to be a best practice. Logically, there is some sense to this approach, since it potentially allows the consumer bundle to gracefully handle broken service dependencies. Of course, this depends on whether there is anything the bundle can do in the face of broken dependencies. If service API packages are embedded in the consumer bundle, then it should export and import the packages. An alternative approach in this case is to dynamically import the service API (or even use optional imports if the dependency should only be considered once).

The main advantages of embedding service API packages in bundles are that the dependencies can always be resolved and it does not require installing a lot of other bundles to resolve the dependencies. There are disadvantages, however. One disadvantage is resource consumption caused by potential code duplication. Probably a more serious disadvantage is that it makes it harder to dynamically swap out providers.

For example, assume a provider bundle is used to export service API packages and all consumers are wired to that bundle. If the provider bundle is updated or uninstalled and then refreshed, then all consumer bundles will be stopped and refreshed as well. Even without a refresh, such a configuration would potentially inhibit garbage collection of the class loader of the service provider, since consumers would be using it for the API package.

This situation would be different if the service API were package in a separate bundle. In this situation, all consumer bundles would be wired to the API bundle, not to the provider bundle. Thus, if the provider were updated or uninstalled and then refreshed, the consumer bundles would only be minimally impacted (i.e., they would either switch to the new version of the provider or to a different provider).

Should a bundle import its own exported packages?

...