"Best practices" resource for OSGi system bundle

GENERAL
1

Hi,

I have a general question regarding the “best practices” for populating the OSGi system bundle please.

The OSGi documentation describes the system bundle as containing both the OSGi framework (no surprise there, since it implements org.osgi.framework.launcher.Framework) and the packages implemented by the JVM itself. And I’ve also noticed that packages from a host application can be “exported” into an embedded framework’s system bundle so that the host app and framework can communicate with each other. This all makes sense to me, and I have been regarding the system bundle as one that does not “require” anything that it cannot “provide” itself.

However, I have recently discovered an instance of a system bundle which doesn’t do this. Which is to say, the framework’s org.framework.system.packages.extra property lists packages whose “uses” directives refer to other packages that are not exported by the system bundle.

I don’t understand how a system bundle like this can be “right”, but I also cannot find any resource that declares it to be definitively “wrong” either. (Although by the same token, nor does my gas oven have a sign advising me not to stick my head inside - YMMV!) It does beg the question of how OSGi is currently parsing those “uses” directives that contain unexported packages though?! After all, it’s not as if the system bundle has a property equivalent for Import-Package to provide those packages with version ranges.

Can anyone point me to a document or resource that can resolve this point either way please?

Thanks,
Chris

2

org.framework.system.packages.extra is for the framework to export some additional package which are known to be available to all bundle’s parent class loader. There is no value in any uses directives here since the listed packages are never submitted to a resolver for resolution. The framework simply assumes the packages are present and they become “exported” from the system bundle for the purposes of resolving bundles which import one of those packages.

3

Hi, thanks for replying. So by the sound of it, if the classes in these extra “system” packages do “use” any classes in other packages then the JVM will need to resolve them in the standard Java way using the classes’ own ClassLoader, which is likely to be the AppClassLoader. And hence this is likely to leak extra (and potentially conflicting?) packages into the OSGi framework. Have I understood you correctly, please?

Thanks,
Chris

4

No. All the extra system packages means is that the system bundle will blindly export them. That’s all. The system bundle is never resolved, so any uses directives on the extra packages are pointless and ignored.

5

OK, maybe poor phrasing on my part. When I said

resolve them in the standard Java way

I meant “non-OSGi class loading and linking”, i.e. from the AppClassLoader or some kind of URLClassLoader.

The system bundle is never resolved, …

Thanks, I think this is a succinct description of what is happening.
Cheers,
Chris