Hi Lucas, Am Freitag, den 04.01.2008, 12:11 -0200 schrieb Lucas Galfaso: > I am trying to see your specific perspective on this issue, but can > you what is wrong with this reasoning: > > <quote> > 3.8.5 Parent Class Loader > [...] > A bundle must not declare imports or exports for java.* packages; > doing so is an error and any such bundle must fail to install. All > other packages available through the parent class loader must be > hidden from executing bundles. > > However, the Framework must explicitly export relevant packages from > the parent class loader. The system property > org.osgi.framework.system.packages > contains the export packages descriptions for the system bundle. > [...] > </quote> > > <comment> > Ok, so there should be a system property of the specific "relevant" > packages that will be delegated to the parent class loader. > </comment>
Yes, its name is "org.osgi.framework.system.packages" > > <quote> > The system bundle (bundle ID zero) is used to export non-java.* > packages from the parent class loader. Export definitions from the > system bundle are treated like normal exports, meaning that they can > have version numbers, and are used to resolve import definitions as > part of the normal bundle resolving process. Other bundles may provide > alternative implementations of the same packages. > </quote> > > <comment> > So the system bundle should be used to export all non-java.* packages > that you want to delegate to the parent class loader (in this case to > look for P1 if P1 should be resolved to the parent class loader.) > </comment> Yes, these are the packages listed in the "org.osgi.framework.system.packages" property. > > <quote> > The set of export definitions for the parent class loader can either > be set by this property or calculated by the Framework. The export > definitions must have the implementation specific bundle symbolic name > and version value of the system bundle. > </quote> > > <comment> > You can use whatever mechanism to create this property, but if it is > "relevant" then it must be there. Now, specifying the system property > org.osgi.framework.bootdelegation > to include P1, then this is a mechanism to make P1 "relevant". No. We are talking about "org.osgi.framework.system.packages" here. The "org.osgi.framework.bootdelegation" property is different as is not a list of exported packages, actually. > > The only way that I am able to think that you may go around this > reasoning is if the user sets "org.osgi.framework.bootdelegation" to > include P1 and also sets the system property > "org.osgi.framework.system.packages" not to include P1, but this is > just a missconfiguraiton as P1 is "relevant" and it was not included > in "org.osgi.framework.system.packages". The standard does not specify > how to handle this scenario (just like it does not state how to handle > the case that these properties does not meet the specified grammar) > but you have to think that everything is properly configured. > </comment> Wrong. Both properties are defined by the spec with different semantics (though similar wording). > > You seem to be very sure that this is not the way this should be > interpreted, so I think my understanding has to be somehow flawed. Can > you please explain me what is wrong above. Let me try to explain, by defining what the properties actually do: * org.osgi.framework.system.packages: Enhances the export list of the system bundles. All packages listed content for bundle resolution just like any export. If for example this property lists package "org.sample.foo;version=1" and some bundle Bx exports "org.sample.foo;version=2", then an import "org.sample.foo" will resolve to Bx and not the system bundle (and hence the parent class loader) just because of the higher version number (See Section 3.8 Resolving Process). * org.osgi.framework.bootdelegation: Extends the class resolution process. This property has nothing to do with imports and exports. It just lists packages whose classes are ALWAYS loaded from the parent class loader, ignoring any imports and wires (See Section 3.8.4 Overall Search Order). Hope this helps. Regards Felix > > Thanks, > Lucas > > > On Jan 4, 2008 10:49 AM, Stuart McCulloch <[EMAIL PROTECTED]> wrote: > > On 04/01/2008, Lucas Galfaso <[EMAIL PROTECTED]> wrote: > > > > > > Hi All, > > > > > > On Jan 4, 2008 7:19 AM, Felix Meschberger <[EMAIL PROTECTED]> wrote: > > > > Hi all, > > > > > > > > In Apache Sling [1] we had an issue regarding classloading [2], which we > > > > could solve by using the org.osgi.framework.bootdelegation property and > > > > sharing a library. Even though the solution with the bootdelegation > > > > property works, we noticed an interesting situation (see also [3]): > > > > > > > > Consider bundle B1 exporting package P1 and Bundle B2 importing Package > > > > P1. In addition the bootdelegation property is set to include P1. > > > > > > > > When B2 is resolved (assuming B1 is active), the Felix framework > > > > correctly resolves the import of P1 to the bundle B1. When a class from > > > > P1 is accessed (in both B1 and B2), the class is of course loaded > > > > correctly from the parent class loader as P1 is listed in the > > > > bootdelegation property. > > > > > > From my perspective, I think this is wrong, P1 should not be resolved > > > to B1 but to the system bundle (unless there is a specific version > > > constraint.) This is the reason (this is copy&paste from v4.1 of the > > > standard): > > > > > > it depends on the setting of the "org.osgi.framework.system.packages" > > property as explained near the start of section 3.8.5 (p55 in R4.1 spec): > > > > "However, the Framework must explicitly export relevant packages from the > > parent class loader. The system property > > > > org.osgi.framework.system.packages > > > > contains the export packages descriptions for the system bundle" > > > > so if P1 is not in "org.osgi.framework.system.packages" then it would > > be resolved to B1 in this particular case, because the system bundle > > wouldn't automatically export P1. > > > > 3.8.5 > > > [...] > > > The system bundle (bundle ID zero) is used to export non-java.* packages > > > from the parent class loader. Export definitions from the system bundle > > > are > > > treated like normal exports, meaning that they can have version numbers, > > > and are used to resolve import definitions as part of the normal bundle > > > resolving process. Other bundles may provide alternative implementations > > > of the same packages. > > > [...] > > > > > > 3.7 Resolving Process > > > [...] > > > The following list defines the preferences, if multiple choices are > > > possible, > > > in order of decreasing priority: > > > - A resolved exporter must be preferred over an unresolved exporter. > > > - An exporter with a higher version is preferred over an exporter with > > > a lower version. > > > - An exporter with a lower bundle ID is preferred over a bundle with a > > > higher ID. > > > > > > The system bundle better to be resolved :-p and has id 0, so if there > > > is no version constraints it should resolve to this bundle. > > > > > > > > > > > The question now is: Is it correct to resolve B2's import of P1 to B1 ? > > > > Or should imported packages listed in the bootdelegation property not be > > > > resolved to other bundles ? > > > > > > They should be resolved, but to the system bundle. > > > > > > the bootdelegation property is separate from the system bundle and > > "org.osgi.framework.system.packages" property - regardless of where > > B2's imports are resolved, class load requests for P1 will delegate to > > the parent classloader first if P1 is listed under bootdelegation > > > > but B2's imports should still be resolved even when P1 is included in > > the bootdelegation list, for flexibility and in case the parent classloader > > cannot provide P1 but another bundle (or the system bundle) can. > > > > Regards, > > > Lucas > > > > > > > Regards > > > > Felix > > > > > > > > > > > -- > > Cheers, Stuart > >
