Awesome! :) Thank you Tom, - Ray
On Mon, Aug 12, 2013 at 1:23 PM, Thomas Watson <[email protected]> wrote: > Sorry for the confusion. I see now you were asking what classes the > extension bundle itself has access to. I was answering a different > question about what "normal" bundles have access to with respect to > packages contained in system bundle fragments. So to clarify the answer: > > 1) framework extensions should have access to all the same classes the > framework implementation does through the class path of the class loader > which loaded the framework. This includes all the necessary > org.osgi.framework packages which are required for the framework > implementation. > 2) boot class path extensions only have access to other content contained > on the boot class path. In most cases this does not include the > org.osgi.framework packages or the framework implementation. > > Tom > > > > [image: Inactive hide details for Raymond Auge ---08/12/2013 10:58:29 > AM---I'm just wondering if an "Extension Bundle", as per section]Raymond > Auge ---08/12/2013 10:58:29 AM---I'm just wondering if an "Extension > Bundle", as per section 3.15 of the spec, has access to the same > > > From: Raymond Auge <[email protected]> > To: OSGi Developer Mail List <[email protected]>, > Date: 08/12/2013 10:58 AM > > Subject: Re: [osgi-dev] clarification about ext bundles class access > Sent by: [email protected] > ------------------------------ > > > > 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]*<[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* <http://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]*<[email protected]> > > > To: OSGi Developer Mail List > <*[email protected]*<[email protected]>>, > > Date: 08/12/2013 10:16 AM > Subject: Re: [osgi-dev] clarification about ext bundles class access > > Sent by: *[email protected]*<[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]* <[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
