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 heavy@ungoverned.org
 designates 69.89.20.235 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=ungoverned.org;
	h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-Identified-User;
	b=rBxuKZWnMdgywkiFr9X/ujF1kwda1dnnwKAT/27oOO/d2qQWHDcSI41DkVgIp+M8g7OaTwnyWylOu4pzlHhuUBy3O12zCKS9goym4+G0ft94KWVngLeTyRRCmXGamK/3;
Message-ID: <48F4A6F1.5000706@ungoverned.org>
Date: Tue, 14 Oct 2008 10:04:33 -0400
From: "Richard S. Hall" <heavy@ungoverned.org>
User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914)
MIME-Version: 1.0
To: dev@felix.apache.org
Subject: Re: Note sure org.osgi.framework.bootdelegation is working
References: <48F44C94.4010106@ascert.com>
	 <87eb8aee0810140102n30bf4c02leeb829d4d2ac6381@mail.gmail.com>
	 <48F4535B.8040904@ascert.com>
 <81f0d9c0810140115r75c9458fhf74e0103d57da134@mail.gmail.com>
In-Reply-To: <81f0d9c0810140115r75c9458fhf74e0103d57da134@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Stuart McCulloch wrote:
> 2008/10/14 Rob Walker <robw@ascert.com>
>
>   
>> Ok - thanks Alin, new area to me and that wasn't how I read the
>> bootdelegation aspect
>>
>> It looked to me as if bootdelegation should be a sort of "super override"
>> or fallback for any/all wildcard package names that weren't explicitly
>> listed as system packages. I'll change our manifest generation to not
>> include imports for any com.sun.* or sun.* in a similar way we do for
>> java.*.
>>
>>     
>
> bootdelegation is used in class loading/resolution (only as a last resort)
> but it isn't used in the resolving of bundle constraints, such as imports.
> So if your bundle has an import on "sun.foo.whatever" then this must be
> provided by another bundle, otherwise the framework won't even begin to
> resolve the bundle and its classes.
>   

To be clear, boot delegation should only be *used* as a last resort, 
because when you set the property then it overrides all other wiring for 
that package and always loads it from the parent class loader.

The boot delegation propery makes it so that all bundles automatically 
get access to the specified packages without having to import them, just 
like the java.* packages. If a bundle actually has an import for the 
package, then you will still need an exporter of the package so that the 
resolver can resolve the import; however, as mentioned, the exporter 
will actually never be used if you have boot delegation set for that 
package.

The best way to make a class path package available to bundles is via 
the system packages property. This still requires the bundle to have an 
import for the package and still does allow for other 
implementations/wirings. In this case, you should not set boot 
delegation for that package.

-> richard

> as Alin mentioned, you can also mark import constraints as optional using
> ";resolution:=optional".
>
> Regards
>   
>> -- Rob
>>
>>
>> Alin Dreghiciu wrote:
>>
>>     
>>> If your bundle has an import for that package (com.sun.jdmk.comm) the
>>> package has to be resolved by the framework, hence it must be exported
>>> by a bundle so by adding the package to the list of system packages,
>>> the package will be resolved. Just adding com.sun.* or something like
>>> that to boot delegation will not be enough, as this is just about how
>>> the classes are loaded. From the specs, to me, it sounds as an
>>> expected behavior. Not 100%sure but if you would add to that import,
>>> that the package is optional the boot delegation should work. And will
>>> work for sure if the import is not present at all.
>>>
>>> On Tue, Oct 14, 2008 at 10:39 AM, Rob Walker <robw@ascert.com> wrote:
>>>
>>>
>>>       
>>>> Getting a few unresolved constraints thrown e.g.
>>>>
>>>>  ERROR: Error starting file:e:\data\tas/lib/tas/testrunner.jar
>>>>  (org.osgi.framewor
>>>>  k.BundleException: Unresolved constraint in bundle 27: package;
>>>>  (package=com.sun
>>>>  .jdmk.comm))
>>>>
>>>> If I manually add this to the bootdelegation property, it doesn't get
>>>> picked
>>>> up.
>>>>
>>>> Adding it to the regular system packages properties gets rid of the
>>>> error.
>>>>
>>>> Wondering if the above property is not yet working and/or maybe the .*
>>>> wildcard/regex aspect isn't wired in?
>>>>
>>>> Will carry on investigating - see if I can see the cause.
>>>>
>>>> -- Rob
>>>>
>>>>
>>>> Ascert - Taking systems to the Edge
>>>> robw@ascert.com
>>>> +44 (0)20 7488 3470
>>>> www.ascert.com
>>>>
>>>>
>>>>
>>>>
>>>>         
>>>
>>>
>>>
>>>       
>> --
>>
>>
>> Ascert - Taking systems to the Edge
>> robw@ascert.com
>> +44 (0)20 7488 3470
>> www.ascert.com
>>
>>
>>     
>
>
>