You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Felix Meschberger <fm...@gmail.com> on 2008/01/04 10:19:47 UTC
Interesting observation regarding org.osgi.framework.bootdelegation
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.
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 ?
My explanation would be: If you declare the import, it must be resolved,
no matter what. To prevent the resolution, the import must not be
declared. But then I assume that packages declared in the bootdelegation
property never need to be declared as imports, right ?
Is may assumption correct ?
In fact, thinking about this situation while writing it down, I am
tempted to not list P1 in the bootdelegation but in the
org.osgi.framework.system.packages property. In this case both B1 (which
also must import its own exports) and B2 would resolve P1 to the system
bundle, which would be better - from an administrative and support
perspective. WDYT ?
Thanks for any hints.
Regards
Felix
[1] http://incubator.apache.org/sling/
[2]
http://www.mail-archive.com/sling-dev@incubator.apache.org/msg01518.html
[3]
http://www.mail-archive.com/sling-dev@incubator.apache.org/msg01567.html
Re: Interesting observation regarding org.osgi.framework.bootdelegation
Posted by Lucas Galfaso <lg...@gmail.com>.
Ok, thanks all for the info
On Jan 4, 2008 2:41 PM, Richard S. Hall <he...@ungoverned.org> 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 <st...@jayway.net> wrote:
> >>
> >>> On 04/01/2008, Lucas Galfaso <lg...@gmail.com> wrote:
> >>>
> >>>> Hi All,
> >>>>
> >>>> On Jan 4, 2008 7:19 AM, Felix Meschberger <fm...@gmail.com> 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
> >>>
> >>>
> >
> >
>
Re: Interesting observation
regarding org.osgi.framework.bootdelegation
Posted by Felix Meschberger <fm...@gmail.com>.
Hi Richard,
Am Freitag, den 04.01.2008, 11:41 -0500 schrieb Richard S. Hall:
> 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.
Thanks. Will probably go that direction.
Regards
Felix
Re: Interesting observation regarding org.osgi.framework.bootdelegation
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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 <st...@jayway.net> wrote:
>>
>>> On 04/01/2008, Lucas Galfaso <lg...@gmail.com> wrote:
>>>
>>>> Hi All,
>>>>
>>>> On Jan 4, 2008 7:19 AM, Felix Meschberger <fm...@gmail.com> 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
>>>
>>>
>
>
Re: Interesting observation regarding
org.osgi.framework.bootdelegation
Posted by Felix Meschberger <fm...@gmail.com>.
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 <st...@jayway.net> wrote:
> > On 04/01/2008, Lucas Galfaso <lg...@gmail.com> wrote:
> > >
> > > Hi All,
> > >
> > > On Jan 4, 2008 7:19 AM, Felix Meschberger <fm...@gmail.com> 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
> >
Re: Interesting observation regarding org.osgi.framework.bootdelegation
Posted by Lucas Galfaso <lg...@gmail.com>.
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>
<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>
<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".
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>
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.
Thanks,
Lucas
On Jan 4, 2008 10:49 AM, Stuart McCulloch <st...@jayway.net> wrote:
> On 04/01/2008, Lucas Galfaso <lg...@gmail.com> wrote:
> >
> > Hi All,
> >
> > On Jan 4, 2008 7:19 AM, Felix Meschberger <fm...@gmail.com> 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
>
Re: Interesting observation regarding org.osgi.framework.bootdelegation
Posted by Stuart McCulloch <st...@jayway.net>.
On 04/01/2008, Lucas Galfaso <lg...@gmail.com> wrote:
>
> Hi All,
>
> On Jan 4, 2008 7:19 AM, Felix Meschberger <fm...@gmail.com> 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
Re: Interesting observation regarding org.osgi.framework.bootdelegation
Posted by Lucas Galfaso <lg...@gmail.com>.
Hi All,
On Jan 4, 2008 7:19 AM, Felix Meschberger <fm...@gmail.com> 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):
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.
Regards,
Lucas
> Regards
> Felix
Re: Interesting observation regarding
org.osgi.framework.bootdelegation
Posted by Felix Meschberger <fm...@gmail.com>.
Hi Stuart,
Thanks for your comments. They perfectly match, what I came to thinking
of while writing the mail :-)
Regards
Felix
Am Freitag, den 04.01.2008, 19:51 +0800 schrieb Stuart McCulloch:
> On 04/01/2008, Felix Meschberger <fm...@gmail.com> 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.
> >
> > 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 ?
>
>
> Well from the perspective of solving bundle constraints, I think it's valid
> semantically to resolve B2's import of P1 to B1, although in practice the
> framework would delegate class load requests from P1 to the parent
> classloader before using B1's classloader, because of bootdelegation.
>
> Otherwise you could have a situation where the parent classloader can't
> provide P1, but a bundle could - but because P1 was in the bootdelegation
> property that import wire was never resolved :(
>
> My explanation would be: If you declare the import, it must be resolved,
> > no matter what. To prevent the resolution, the import must not be
> > declared. But then I assume that packages declared in the bootdelegation
> > property never need to be declared as imports, right ?
>
>
> Yes, as long as the parent classloader can supply them :)
>
> If you do declare them as imports then it's just an additional constraint
> that's not strictly necessary, but it would give you some flexibility in the
> future if you decided to move from bootdelegation (see below)
>
> Is may assumption correct ?
> >
> > In fact, thinking about this situation while writing it down, I am
> > tempted to not list P1 in the bootdelegation but in the
> > org.osgi.framework.system.packages property. In this case both B1 (which
> > also must import its own exports) and B2 would resolve P1 to the system
> > bundle, which would be better - from an administrative and support
> > perspective. WDYT ?
>
>
> it's recommended to always import your exports (BND does this for you)
>
> I see two main scenarios:
>
> 1) P1 is in the bootdelegation property and is available from
> the parent classloader (ie. the containing/boot classloader)
>
> B2 then doesn't need to explicitly import P1
>
> 2) P1 is in the org.osgi.framework.system.packages property
> and is therefore exported by the framework system bundle
>
> B2 needs to explicitly import P1
>
> imho 2) is better, as the dependency is explicit and you could easily
> switch to providing P1 from a non-system bundle without needing to
> rebuild B2 (and therefore get the true benefits of OSGi)
>
> but in some legacy situations you may need to use 1) because of
> assumptions about the classloading hierarchy in third-party code...
>
> HTH
>
> Thanks for any hints.
> >
> > Regards
> > Felix
> >
> > [1] http://incubator.apache.org/sling/
> > [2]
> > http://www.mail-archive.com/sling-dev@incubator.apache.org/msg01518.html
> > [3]
> > http://www.mail-archive.com/sling-dev@incubator.apache.org/msg01567.html
> >
> >
>
>
Re: Interesting observation regarding org.osgi.framework.bootdelegation
Posted by Stuart McCulloch <st...@jayway.net>.
On 04/01/2008, Felix Meschberger <fm...@gmail.com> 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.
>
> 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 ?
Well from the perspective of solving bundle constraints, I think it's valid
semantically to resolve B2's import of P1 to B1, although in practice the
framework would delegate class load requests from P1 to the parent
classloader before using B1's classloader, because of bootdelegation.
Otherwise you could have a situation where the parent classloader can't
provide P1, but a bundle could - but because P1 was in the bootdelegation
property that import wire was never resolved :(
My explanation would be: If you declare the import, it must be resolved,
> no matter what. To prevent the resolution, the import must not be
> declared. But then I assume that packages declared in the bootdelegation
> property never need to be declared as imports, right ?
Yes, as long as the parent classloader can supply them :)
If you do declare them as imports then it's just an additional constraint
that's not strictly necessary, but it would give you some flexibility in the
future if you decided to move from bootdelegation (see below)
Is may assumption correct ?
>
> In fact, thinking about this situation while writing it down, I am
> tempted to not list P1 in the bootdelegation but in the
> org.osgi.framework.system.packages property. In this case both B1 (which
> also must import its own exports) and B2 would resolve P1 to the system
> bundle, which would be better - from an administrative and support
> perspective. WDYT ?
it's recommended to always import your exports (BND does this for you)
I see two main scenarios:
1) P1 is in the bootdelegation property and is available from
the parent classloader (ie. the containing/boot classloader)
B2 then doesn't need to explicitly import P1
2) P1 is in the org.osgi.framework.system.packages property
and is therefore exported by the framework system bundle
B2 needs to explicitly import P1
imho 2) is better, as the dependency is explicit and you could easily
switch to providing P1 from a non-system bundle without needing to
rebuild B2 (and therefore get the true benefits of OSGi)
but in some legacy situations you may need to use 1) because of
assumptions about the classloading hierarchy in third-party code...
HTH
Thanks for any hints.
>
> Regards
> Felix
>
> [1] http://incubator.apache.org/sling/
> [2]
> http://www.mail-archive.com/sling-dev@incubator.apache.org/msg01518.html
> [3]
> http://www.mail-archive.com/sling-dev@incubator.apache.org/msg01567.html
>
>
--
Cheers, Stuart