I'm just wondering if an "Extension Bundle", as per section 3.15 of the spec, has access to the same class space as the system bundle... not to see other extension bundles, but to know if it can see the "internal" classes within the system bundle, and whether there was a distinction with respect to bootclasspath vs. framework extensions.
You clarified the bootclasspath part, and I believe that we have come to an understanding of the framework as well. Thanks On Mon, Aug 12, 2013 at 11:49 AM, Thomas Watson <[email protected]> wrote: > Are you talking about system bundle fragments having access to content > from other system bundle fragments? In this case, yes the system bundle > fragments cannot depend on each others packages using Import-Package, but > they should have access to each others content at runtime as long as they > are framework extensions. At least for Equinox this is true for framework > extensions because they are all loaded by the same class loader. If boot > class path extensions were supported then these fragments cannot have > access to content on the framework's class loader because the boot class > loader is self-contained and never delegates out to another class loader. > > Such dependencies are not allowed to be specified between the framework > extensions since the specification does not even allow for the > Require-Capability header (except for non-payload requirements like > osgi.ee). So at runtime I think you would have to treat such > dependencies as optional at best so that your extension does not fail > miserably if the other extension is not present. > > Tom > > > > [image: Inactive hide details for Raymond Auge ---08/12/2013 10:16:17 > AM---There is one problem with your explanation: "3.15.1 Illegal]Raymond > Auge ---08/12/2013 10:16:17 AM---There is one problem with your > explanation: "3.15.1 Illegal Manifest Headers for Extension Bundles > > > From: Raymond Auge <[email protected]> > To: OSGi Developer Mail List <[email protected]>, > Date: 08/12/2013 10:16 AM > Subject: Re: [osgi-dev] clarification about ext bundles class access > > Sent by: [email protected] > ------------------------------ > > > > 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]*<[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 > > *<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 > > *<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]*<[email protected]> > > > To: OSGi Developer Mail List > <*[email protected]*<[email protected]>>, > > Date: 08/12/2013 09:42 AM > Subject: [osgi-dev] clarification about ext bundles class access > Sent by: *[email protected]*<[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]* <[email protected]>* > > **https://mail.osgi.org/mailman/listinfo/osgi-dev*<https://mail.osgi.org/mailman/listinfo/osgi-dev> > > _______________________________________________ > OSGi Developer Mail List* > **[email protected]* <[email protected]>* > > **https://mail.osgi.org/mailman/listinfo/osgi-dev*<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) > _______________________________________________ > 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
