You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Rob Walker <ro...@ascert.com> on 2008/10/14 09:39:00 UTC
Note sure org.osgi.framework.bootdelegation is working
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
Re: Note sure org.osgi.framework.bootdelegation is working
Posted by "Richard S. Hall" <he...@ungoverned.org>.
Stuart McCulloch wrote:
> 2008/10/14 Rob Walker <ro...@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 <ro...@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
>>
>>
>>
>
>
>
Re: Note sure org.osgi.framework.bootdelegation is working
Posted by Stuart McCulloch <mc...@gmail.com>.
2008/10/14 Rob Walker <ro...@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.
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 <ro...@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
>
>
--
Cheers, Stuart
Re: Note sure org.osgi.framework.bootdelegation is working
Posted by Rob Walker <ro...@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.*.
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 <ro...@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
Re: Note sure org.osgi.framework.bootdelegation is working
Posted by Alin Dreghiciu <ad...@gmail.com>.
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 <ro...@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
>
>
--
Alin Dreghiciu
http://www.ops4j.org - New Energy for OSS Communities - Open
Participation Software.
http://www.qi4j.org - New Energy for Java - Domain Driven
Development.
http://malaysia.jayway.net - New Energy for Projects - Great People
working on Great Projects at Great Places