CODEWITHSUNDEEP
javadependenciesosgi
chimericdream
chimericdream

Reputation: 432

Enforcing OSGi package imports

tl;dr

We have two groups of bundles. Call them Group A and Group B. Bundles in Group A MUST import packages from ONLY other bundles in Group A, regardless of whether some bundle in Group B exports a package which could satisfy the dependency. Bundles in Group B MAY resolve their package imports from any bundle, regardless of whether it is in Group A or Group B.

Longer explanation

My team is trying to find a way to enforce a kind of "safe mode" for a product built using OSGi. Essentially we have our core product, and we allow customers to install their own components on top to extend our functionality. Obviously, this is the type of thing OSGi is made for.

However, we have noticed that if a customer installs a bundle which happens to export a package used by one of our core bundles, there is a chance that the core bundle will get wired up to something installed by a third party. While I understand that semantic versioning implies that this is not a major cause for concern, we have noticed that a significant portion of our core bundles are restarted if/when some third party bundles are refreshed.

What we want to do is ensure that bundles in our core product do not wire up to any bundle installed by a third party. We are using bundle start levels to set our core bundles to a start level before third party bundles. This lets us set the framework start level to exclude all bundles after our core in the event that we need to debug issues with third party code. However, start levels alone are not enough to prevent package level dependencies from wiring up to our core components.

The only way I can think of to do this (which I do not believe is a good solution and we have no plan to implement) is to maintain a list of all third party bundles added to the runtime after our core product is set up. Then, when the framework shuts down, uninstall all bundles in this list (backing up the actual bundle file). On startup, the core product would start and wire up correctly, then we'd automate the re-installation of all the third party bundles that have been installed. This feels to me like a very fragile, hacky, and just plain wrong way to achieve what we want, but I can't think of any other way. So I am turning to the SO community for help!

Upvotes: 1

Views: 155

Answers (1)

Peter Kriens
Peter Kriens

Reputation: 15372

If you have developed your system around services then sometimes the best approach is to start another framework and run the customer code in the other framework. If you're more classic Java oriented then this is too much work usually.

Then there are a number of possibilities:

  • Resolve Hooks – With these hooks you can hide bundles and very likely control things exactly as you want.
  • Security – With the security manager you can limit package imports and exports
  • Attributes – Export packages from the core with a magic attribute and import only when that attribute is set.
  • Weaving – Have a weaving hook that adds a non-existent package import to every non-core bundle. Initialize core, synthesize a bundle with the non-existent package and install/resolve it.

Obviously both Resolve Hooks and Weaving require your bundle to run very early. If you use the Bndtools launcher then there is a way to do this.

Upvotes: 1

Related Questions