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 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]> 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 Inactive hide details for Raymond Auge ---08/12/2013 09:42:22 AM---I just want to clarify the distinction between Fragment-HostRaymond 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é (@rotty3000) Senior Software Architect Liferay, Inc. (@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é (@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
