Mailing-List: contact dev-help@felix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@felix.apache.org
Received-SPF: pass (athena.apache.org: domain of lgalfaso@gmail.com designates
 64.233.178.240 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=sPPayqdTCyOf0jNGQ2ZkfbIdLzjSkEGtDN99nib2HHmQVNrAT9O7Nb9xUYrdrXtMGmLvLaB7v9WKnhPSH+9ZlcNdqc3dgo85JkkNTYRtAw/IDy71taCZWYxcYCPjJV6M4OQJqJFjtRaWfWyYCfQg7GMPh1J4dbutm+vlEhS+Koo=
Message-ID: <ddeae1ee0801040908u1d5b9c4dt8e5e8bdd3013c355@mail.gmail.com>
Date: Fri, 4 Jan 2008 15:08:16 -0200
From: "Lucas Galfaso" <lgalfaso@gmail.com>
To: dev@felix.apache.org
Subject: Re: Interesting observation regarding
 org.osgi.framework.bootdelegation
In-Reply-To: <477E619E.7010708@ungoverned.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <1199438387.8080.86.camel@bslm-046.corp.day.com>
	 <ddeae1ee0801040407y4fe13e66k23c9cc7e9aed64b0@mail.gmail.com>
	 <81f0d9c0801040449va177d46idf2101324b16a7ce@mail.gmail.com>
	 <ddeae1ee0801040611m5fc4e545h124f1b03fdfcafd@mail.gmail.com>
	 <1199460383.670.38.camel@bslm-046.corp.day.com>
	 <477E619E.7010708@ungoverned.org>

Ok, thanks all for the info

On Jan 4, 2008 2:41 PM, Richard S. Hall <heavy@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 <stuart.mcculloch@jayway.net> wrote:
> >>
> >>> On 04/01/2008, Lucas Galfaso <lgalfaso@gmail.com> wrote:
> >>>
> >>>> Hi All,
> >>>>
> >>>> On Jan 4, 2008 7:19 AM, Felix Meschberger <fmeschbe@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
> >>>
> >>>
> >
> >
>