There is one problem with your explanation: "3.15.1 Illegal Manifest Headers for Extension Bundles An extension bundle must throw a BundleException if it is installed or updated and it specifies any of the following headers.
Import-Package ... DynamicImport-Package ... " Wouldn't this mean that a ext bundle, since it cannot use the Import-Package header, itself must have the same class space as the system bundle somehow? On Mon, Aug 12, 2013 at 11:05 AM, Thomas Watson <[email protected]> wrote: > 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 > > > > [image: Inactive hide details for Raymond Auge ---08/12/2013 09:42:22 > AM---I just want to clarify the distinction between Fragment-Host]Raymond > Auge ---08/12/2013 09:42:22 AM---I just want to clarify the distinction > between Fragment-Host: system.bundle; extension:=framework > > 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é* <http://www.liferay.com/web/raymond.auge/profile> > (@rotty3000) > Senior Software Architect > *Liferay, Inc.* <http://www.liferay.com/> (@Liferay) > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev > > > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev > -- *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000) Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> (@Liferay)
<<graycol.gif>>
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
