Ok, thanks all for the info
On Jan 4, 2008 2:41 PM, Richard S. Hall <[EMAIL PROTECTED]> wrote: > Lucas, > > I understand you thinking, but it is not correct from my recollection of > how we defined these properties. Felix' explanation below is correct, > the two properties are completely separate. > > Boot delegation does not impact import/export resolution at all. If you > want that, then use system packages. > > We accepted the fact that boot delegation would short-circuit wired > packages like Felix first described. The reason was that this was > similar to behavior that was already present in R3 implementations, > since the R3 spec said that you always delegated to the parent class > loader first. Thus, you could end up with wires that were being > short-circuited there too. > > It is definitely not the case that boot delegation packages were > supposed to be automatically added to system packages in any fashion. > > To answer Felix' original question, I would go with exporting them as > system packages if that works, since that is the best long-term solution > with regards to being able to migrate to non-system packages and also it > doesn't hide the dependencies. > > -> richard > > > Felix Meschberger wrote: > > 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 > >>> > >>> > > > > >
