If the fragment exports the packages then there should be no distinction. All client bundles have to use Import-Package to get access to the exported packages. The packages at runtime are exported by the system bundle. The framework is responsible for making sure the bundle that import the package have access to the actual content regardless of where the actual classes get loaded from (i.e. the framework's own class loader or the boot class loader).
As far as I know no framework exists that supports bootclasspath extensions. I feel we should consider removing this from the specification unless someone is really going to implement it. It only causes confusion in the specification. But the theory is that bootclasspath extensions get configured into the VM's boot classpath and framework extensions get configured into the class loader used to actually load the framework implementation. The two frameworks I am most familiar with (Equinox and Felix) do this by assuming the framework implementation is loaded with a class loader that has an addURL() method (e.g. a URLClassLoader) and reflection is used to add the framework extension to the classpath. In a standard OSGi configuration (no bootdelegation settings), bundles only get free access to the java.* packages. The VM spec tries to limit the boot class loader as the only class loader that can define java.* classes. The bootclasspath extensions were invented to allow bundles to deliver additional java.* packages to the boot class path because normal bundle class loaders are not allowed to define java classes (without using some hacks). This is why I say there is no distinction between the two (framework vs bootclasspath) with respect to a bundle accessing them. If the package is a non-java.* package then clients must use Import-Package. The java.* packages are available with no Import-Package. If the fragment does not export the package then the only way the package can be accessible to the bundle is if you are using some bootclasspath delegation [1] configuration and you have set the bundle parent classloader [2] configuration to the proper classloader (e.g. framework vs boot vs ...). Or the package is a java.* package and the fragment is a bootclasspath extension. But I recommend you do NOT use a boot delegation setting as a best practice and force all clients to use Import-Package to access the packages. Tom [1] - http://www.osgi.org/javadoc/r5/core/org/osgi/framework/Constants.html#FRAMEWORK_BOOTDELEGATION [2] - http://www.osgi.org/javadoc/r5/core/org/osgi/framework/Constants.html#FRAMEWORK_BUNDLE_PARENT From: Raymond Auge <[email protected]> To: OSGi Developer Mail List <[email protected]>, Date: 08/12/2013 09:42 AM Subject: [osgi-dev] clarification about ext bundles class access Sent by: [email protected] I just want to clarify the distinction between Fragment-Host: system.bundle; extension:=framework Fragment-Host: system.bundle; extension:=bootclasspath with respect to classes the bundle has access to. 1) is there a distinction? 2) what about the case when the framework is not itself loading from the bootclasspath (i.e. is loaded by FrameworkFactory in an existing VM) Section 3.15 of core spec doesn't actually clarify these points. Is there some other section on this topic? Sincerely, -- Raymond Augé (@rotty3000) Senior Software Architect Liferay, Inc. (@Liferay) _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
<<inline: graycol.gif>>
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
