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 2010/03/03 10:41:14 UTC
bootdelegation mystery
We've had a couple of instances where boot delegation just doesn't seem
to work for us (we're on Felix trunk, but from a few weeks back).
One was when doing profiling - the other just now with some crypto work.
Our property is set as follows:
org.osgi.framework.bootdelegation=sun.*,com.sun.*
and the exception that gets thrown is:
ERROR: EventDispatcher: Error during dispatch.
(java.lang.NoClassDefFoundError: com/sun/crypto/provider/SunJCE)
java.lang.NoClassDefFoundError: com/sun/crypto/provider/SunJCE
at
com.ascert.webui.vt.server.PreAuthScheme$Util.getScheme(PreAuthScheme.java:57)
at com.ascert.webui.vt.GwtServlet.init(GwtServlet.java:443)
at com.ascert.webui.vt.GwtServlet.activate(GwtServlet.java:359)
at
org.apache.felix.servicebinder.InstanceManager.validate(InstanceManager.java:273)
at
org.apache.felix.servicebinder.InstanceManager$DependencyManager.serviceChanged(InstanceManager.java:948)
at
org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:878)
at
org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:732)
at
org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:662)
at
org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:3601)
I know for sure that class is available on the system classpath - it's
part of the sunjce_provider.jar in JRE lib/ext.
If I add a specific import for the package, I then get the usual
unresolved constraint error:
ERROR: Error starting file:c:\mnt\data\tas/lib/webui/webui.jar
(org.osgi.framework.BundleException: Unresolved constraint in bundle
com.ascert.webui.vt [40]: package; (package=com.sun.crypto.provider))
org.osgi.framework.BundleException: Unresolved constraint in bundle
com.ascert.webui.vt [40]: package; (package=com.sun.crypto.provider)
at
org.apache.felix.framework.Felix.resolveBundle(Felix.java:3277)
at
org.apache.felix.framework.Felix.startBundle(Felix.java:1611)
at
org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1082)
Only by adding the package to the org.osgi.framework.system.packages
list does the error then get cleared e.g.
jre-1.6=
...
org.xml.sax.ext; org.xml.sax.helpers; com.sun.crypto.provider;
version="1.6.0"
Whilst this gets around the error, unless I'm not understanding boot
delegation it seems like a bug. I thought the point to boot delegation
was to allow certain core Java classes, such as the sun.* and com.sun.*
ones to be accessible without specific imports or being listed as system
packages. Not graceful in an OSGi world, but sometimes the most
practical solution for Sun suppler RT and ext classes .
In our case, our bundle is a good citizen and does not use the
com.sun.crypto.provider class in question here - we go via the
javax.crypto API, and this is the one picking up the default
com.sun.crypto.provider class.
Am I missing the point here, or is boot delegation not doing it's job?
-- Rob
Ascert - Taking systems to the Edge
robw@ascert.com
+44 (0)20 7488 3470
www.ascert.com
Re: bootdelegation mystery
Posted by Rob Walker <ro...@ascert.com>.
Just checking the OSGi spec on this -
/1 If the class or resource is in a java.* package, the request is
delegated to
the parent class loader; otherwise, the search continues with the next
step. If the request is delegated to the parent class loader and the
class or
resource is not found, then the search terminates and the request fails.
2 If the class or resource is from a package included in the boot
delegation
list (org.osgi.framework.bootdelegation), then the request is delegated
to the parent class loader. If the class or resource is found there, the
search ends.
3 If the class or resource is in a package that is imported using
Import-
Package or was imported dynamically in a previous load, then the
request is delegated to the exporting bundle's class loader;
otherwise the
search continues with the next step. If the request is delegated to an
exporting class loader and the class or resource is not found, then the
search terminates and the request fails.
/
So according to the spec, java.* and any boot delegation classes should
be check and delegated too before imports are checked. That definitely
does not seem to be happening for the case we are seeing.
I suspect it's a more complex scenario than is typical e.g. the class
looking for the com.sun.* class is a javax.crypto class (which itself is
permitted via the system framework classes) rather than a direct
reference from a class within one of the bundles. I'd guess this messes
with the hiearachy of bundle classloaders in some way.
Unless anyone has any objections, I'll raise a JIRA bug for this.
- Rob
On 03/03/2010 11:41 AM, Rob Walker wrote:
> We've had a couple of instances where boot delegation just doesn't
> seem to work for us (we're on Felix trunk, but from a few weeks back).
>
> One was when doing profiling - the other just now with some crypto work.
>
> Our property is set as follows:
>
> org.osgi.framework.bootdelegation=sun.*,com.sun.*
>
> and the exception that gets thrown is:
>
> ERROR: EventDispatcher: Error during dispatch.
> (java.lang.NoClassDefFoundError: com/sun/crypto/provider/SunJCE)
> java.lang.NoClassDefFoundError: com/sun/crypto/provider/SunJCE
> at
>
> com.ascert.webui.vt.server.PreAuthScheme$Util.getScheme(PreAuthScheme.java:57)
>
> at com.ascert.webui.vt.GwtServlet.init(GwtServlet.java:443)
> at
> com.ascert.webui.vt.GwtServlet.activate(GwtServlet.java:359)
> at
>
> org.apache.felix.servicebinder.InstanceManager.validate(InstanceManager.java:273)
>
> at
>
> org.apache.felix.servicebinder.InstanceManager$DependencyManager.serviceChanged(InstanceManager.java:948)
>
> at
>
> org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:878)
>
> at
>
> org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:732)
>
> at
>
> org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:662)
>
> at
> org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:3601)
>
>
> I know for sure that class is available on the system classpath - it's
> part of the sunjce_provider.jar in JRE lib/ext.
>
> If I add a specific import for the package, I then get the usual
> unresolved constraint error:
>
> ERROR: Error starting file:c:\mnt\data\tas/lib/webui/webui.jar
> (org.osgi.framework.BundleException: Unresolved constraint in bundle
> com.ascert.webui.vt [40]: package; (package=com.sun.crypto.provider))
> org.osgi.framework.BundleException: Unresolved constraint in bundle
> com.ascert.webui.vt [40]: package; (package=com.sun.crypto.provider)
> at
> org.apache.felix.framework.Felix.resolveBundle(Felix.java:3277)
> at
> org.apache.felix.framework.Felix.startBundle(Felix.java:1611)
> at
> org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1082)
>
> Only by adding the package to the org.osgi.framework.system.packages
> list does the error then get cleared e.g.
>
> jre-1.6=
> ...
> org.xml.sax.ext; org.xml.sax.helpers; com.sun.crypto.provider;
> version="1.6.0"
>
> Whilst this gets around the error, unless I'm not understanding boot
> delegation it seems like a bug. I thought the point to boot delegation
> was to allow certain core Java classes, such as the sun.* and
> com.sun.* ones to be accessible without specific imports or being
> listed as system packages. Not graceful in an OSGi world, but
> sometimes the most practical solution for Sun suppler RT and ext
> classes .
>
> In our case, our bundle is a good citizen and does not use the
> com.sun.crypto.provider class in question here - we go via the
> javax.crypto API, and this is the one picking up the default
> com.sun.crypto.provider class.
>
> Am I missing the point here, or is boot delegation not doing it's job?
>
> -- 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: bootdelegation mystery
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 3/3/10 7:30, Richard S. Hall wrote:
> On 3/3/10 4:41, Rob Walker wrote:
>> We've had a couple of instances where boot delegation just doesn't
>> seem to work for us (we're on Felix trunk, but from a few weeks back).
>>
>> One was when doing profiling - the other just now with some crypto work.
>>
>> Our property is set as follows:
>>
>> org.osgi.framework.bootdelegation=sun.*,com.sun.*
>>
>> and the exception that gets thrown is:
>>
>> ERROR: EventDispatcher: Error during dispatch.
>> (java.lang.NoClassDefFoundError: com/sun/crypto/provider/SunJCE)
>> java.lang.NoClassDefFoundError: com/sun/crypto/provider/SunJCE
>> at
>>
>> com.ascert.webui.vt.server.PreAuthScheme$Util.getScheme(PreAuthScheme.java:57)
>>
>> at com.ascert.webui.vt.GwtServlet.init(GwtServlet.java:443)
>> at
>> com.ascert.webui.vt.GwtServlet.activate(GwtServlet.java:359)
>> at
>>
>> org.apache.felix.servicebinder.InstanceManager.validate(InstanceManager.java:273)
>>
>> at
>>
>> org.apache.felix.servicebinder.InstanceManager$DependencyManager.serviceChanged(InstanceManager.java:948)
>>
>> at
>>
>> org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:878)
>>
>> at
>>
>> org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:732)
>>
>> at
>>
>> org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:662)
>>
>> at
>> org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:3601)
>>
>>
>> I know for sure that class is available on the system classpath -
>> it's part of the sunjce_provider.jar in JRE lib/ext.
>>
>> If I add a specific import for the package, I then get the usual
>> unresolved constraint error:
>>
>> ERROR: Error starting file:c:\mnt\data\tas/lib/webui/webui.jar
>> (org.osgi.framework.BundleException: Unresolved constraint in bundle
>> com.ascert.webui.vt [40]: package; (package=com.sun.crypto.provider))
>> org.osgi.framework.BundleException: Unresolved constraint in bundle
>> com.ascert.webui.vt [40]: package; (package=com.sun.crypto.provider)
>> at
>> org.apache.felix.framework.Felix.resolveBundle(Felix.java:3277)
>> at
>> org.apache.felix.framework.Felix.startBundle(Felix.java:1611)
>> at
>> org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1082)
>>
>> Only by adding the package to the org.osgi.framework.system.packages
>> list does the error then get cleared e.g.
>>
>> jre-1.6=
>> ...
>> org.xml.sax.ext; org.xml.sax.helpers; com.sun.crypto.provider;
>> version="1.6.0"
>>
>> Whilst this gets around the error, unless I'm not understanding boot
>> delegation it seems like a bug. I thought the point to boot
>> delegation was to allow certain core Java classes, such as the sun.*
>> and com.sun.* ones to be accessible without specific imports or being
>> listed as system packages. Not graceful in an OSGi world, but
>> sometimes the most practical solution for Sun suppler RT and ext
>> classes .
>>
>> In our case, our bundle is a good citizen and does not use the
>> com.sun.crypto.provider class in question here - we go via the
>> javax.crypto API, and this is the one picking up the default
>> com.sun.crypto.provider class.
>>
>> Am I missing the point here, or is boot delegation not doing it's job?
>
> I think the class loading hierarchy is like this:
>
> boot class loader<-extension class loader<-app class loader
>
> Boot delegation, by default delegates to the boot class loader. If you
> want it to use the extension class loader or the app class loader you
> need to set the following config property:
>
> org.osgi.framework.bundle.parent
>
> It can have one of the following values: boot, ext, app, or framework
> indicating the boot, extension, application, or framework class loader
> respectively.
>
> Try changing this value to "ext" or "app"...when you add packages to
> the system bundle, they are provided by delegating to the framework
> class loader which is typically the app class loader if you use the
> Felix launcher.
For clarification, the last bit about adding packages to the system
bundle was to explain why your issue is likely solved by adding the
packages to the system bundle, since it uses a class loader with
visibility to them.
-> richard
>
> -> richard
>
>>
>> -- Rob
>>
>>
>> Ascert - Taking systems to the Edge
>> robw@ascert.com
>> +44 (0)20 7488 3470
>> www.ascert.com
>>
>>
Re: bootdelegation mystery
Posted by Rob Walker <ro...@ascert.com>.
Thanks guys, will give this a try - hadn't spotted the subtle
distinction there on delegation
- R
On 03/03/2010 2:38 PM, Stuart McCulloch wrote:
> On 3 March 2010 20:30, Richard S. Hall<he...@ungoverned.org> wrote:
>
>
>> On 3/3/10 4:41, Rob Walker wrote:
>>
>>
>>> We've had a couple of instances where boot delegation just doesn't seem to
>>> work for us (we're on Felix trunk, but from a few weeks back).
>>>
>>> One was when doing profiling - the other just now with some crypto work.
>>>
>>> Our property is set as follows:
>>>
>>> org.osgi.framework.bootdelegation=sun.*,com.sun.*
>>>
>>> and the exception that gets thrown is:
>>>
>>> ERROR: EventDispatcher: Error during dispatch.
>>> (java.lang.NoClassDefFoundError: com/sun/crypto/provider/SunJCE)
>>> java.lang.NoClassDefFoundError: com/sun/crypto/provider/SunJCE
>>> at
>>>
>>> com.ascert.webui.vt.server.PreAuthScheme$Util.getScheme(PreAuthScheme.java:57)
>>>
>>> at com.ascert.webui.vt.GwtServlet.init(GwtServlet.java:443)
>>> at com.ascert.webui.vt.GwtServlet.activate(GwtServlet.java:359)
>>> at
>>>
>>> org.apache.felix.servicebinder.InstanceManager.validate(InstanceManager.java:273)
>>>
>>> at
>>>
>>> org.apache.felix.servicebinder.InstanceManager$DependencyManager.serviceChanged(InstanceManager.java:948)
>>>
>>> at
>>>
>>> org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:878)
>>>
>>> at
>>>
>>> org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:732)
>>>
>>> at
>>>
>>> org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:662)
>>>
>>> at
>>> org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:3601)
>>>
>>>
>>> I know for sure that class is available on the system classpath - it's
>>> part of the sunjce_provider.jar in JRE lib/ext.
>>>
>>> If I add a specific import for the package, I then get the usual
>>> unresolved constraint error:
>>>
>>> ERROR: Error starting file:c:\mnt\data\tas/lib/webui/webui.jar
>>> (org.osgi.framework.BundleException: Unresolved constraint in bundle
>>> com.ascert.webui.vt [40]: package; (package=com.sun.crypto.provider))
>>> org.osgi.framework.BundleException: Unresolved constraint in bundle
>>> com.ascert.webui.vt [40]: package; (package=com.sun.crypto.provider)
>>> at
>>> org.apache.felix.framework.Felix.resolveBundle(Felix.java:3277)
>>> at
>>> org.apache.felix.framework.Felix.startBundle(Felix.java:1611)
>>> at
>>> org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1082)
>>>
>>> Only by adding the package to the org.osgi.framework.system.packages list
>>> does the error then get cleared e.g.
>>>
>>> jre-1.6=
>>> ...
>>> org.xml.sax.ext; org.xml.sax.helpers; com.sun.crypto.provider;
>>> version="1.6.0"
>>>
>>> Whilst this gets around the error, unless I'm not understanding boot
>>> delegation it seems like a bug. I thought the point to boot delegation was
>>> to allow certain core Java classes, such as the sun.* and com.sun.* ones to
>>> be accessible without specific imports or being listed as system packages.
>>> Not graceful in an OSGi world, but sometimes the most practical solution
>>> for Sun suppler RT and ext classes .
>>>
>>> In our case, our bundle is a good citizen and does not use the
>>> com.sun.crypto.provider class in question here - we go via the javax.crypto
>>> API, and this is the one picking up the default com.sun.crypto.provider
>>> class.
>>>
>>> Am I missing the point here, or is boot delegation not doing it's job?
>>>
>>>
>> I think the class loading hierarchy is like this:
>>
>> boot class loader<-extension class loader<-app class loader
>>
>>
> yep, that's correct... the boot class loader won't see any extensions
>
>
>
>> Boot delegation, by default delegates to the boot class loader. If you want
>> it to use the extension class loader or the app class loader you need to set
>> the following config property:
>>
>> org.osgi.framework.bundle.parent
>>
>> It can have one of the following values: boot, ext, app, or framework
>> indicating the boot, extension, application, or framework class loader
>> respectively.
>>
>> Try changing this value to "ext" or "app"...when you add packages to the
>> system bundle, they are provided by delegating to the framework class loader
>> which is typically the app class loader if you use the Felix launcher.
>>
>> -> richard
>>
>>
>>
>>
>>> -- 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: bootdelegation mystery
Posted by Stuart McCulloch <mc...@gmail.com>.
On 3 March 2010 20:30, Richard S. Hall <he...@ungoverned.org> wrote:
> On 3/3/10 4:41, Rob Walker wrote:
>
>> We've had a couple of instances where boot delegation just doesn't seem to
>> work for us (we're on Felix trunk, but from a few weeks back).
>>
>> One was when doing profiling - the other just now with some crypto work.
>>
>> Our property is set as follows:
>>
>> org.osgi.framework.bootdelegation=sun.*,com.sun.*
>>
>> and the exception that gets thrown is:
>>
>> ERROR: EventDispatcher: Error during dispatch.
>> (java.lang.NoClassDefFoundError: com/sun/crypto/provider/SunJCE)
>> java.lang.NoClassDefFoundError: com/sun/crypto/provider/SunJCE
>> at
>>
>> com.ascert.webui.vt.server.PreAuthScheme$Util.getScheme(PreAuthScheme.java:57)
>>
>> at com.ascert.webui.vt.GwtServlet.init(GwtServlet.java:443)
>> at com.ascert.webui.vt.GwtServlet.activate(GwtServlet.java:359)
>> at
>>
>> org.apache.felix.servicebinder.InstanceManager.validate(InstanceManager.java:273)
>>
>> at
>>
>> org.apache.felix.servicebinder.InstanceManager$DependencyManager.serviceChanged(InstanceManager.java:948)
>>
>> at
>>
>> org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:878)
>>
>> at
>>
>> org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:732)
>>
>> at
>>
>> org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:662)
>>
>> at
>> org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:3601)
>>
>>
>> I know for sure that class is available on the system classpath - it's
>> part of the sunjce_provider.jar in JRE lib/ext.
>>
>> If I add a specific import for the package, I then get the usual
>> unresolved constraint error:
>>
>> ERROR: Error starting file:c:\mnt\data\tas/lib/webui/webui.jar
>> (org.osgi.framework.BundleException: Unresolved constraint in bundle
>> com.ascert.webui.vt [40]: package; (package=com.sun.crypto.provider))
>> org.osgi.framework.BundleException: Unresolved constraint in bundle
>> com.ascert.webui.vt [40]: package; (package=com.sun.crypto.provider)
>> at
>> org.apache.felix.framework.Felix.resolveBundle(Felix.java:3277)
>> at
>> org.apache.felix.framework.Felix.startBundle(Felix.java:1611)
>> at
>> org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1082)
>>
>> Only by adding the package to the org.osgi.framework.system.packages list
>> does the error then get cleared e.g.
>>
>> jre-1.6=
>> ...
>> org.xml.sax.ext; org.xml.sax.helpers; com.sun.crypto.provider;
>> version="1.6.0"
>>
>> Whilst this gets around the error, unless I'm not understanding boot
>> delegation it seems like a bug. I thought the point to boot delegation was
>> to allow certain core Java classes, such as the sun.* and com.sun.* ones to
>> be accessible without specific imports or being listed as system packages.
>> Not graceful in an OSGi world, but sometimes the most practical solution
>> for Sun suppler RT and ext classes .
>>
>> In our case, our bundle is a good citizen and does not use the
>> com.sun.crypto.provider class in question here - we go via the javax.crypto
>> API, and this is the one picking up the default com.sun.crypto.provider
>> class.
>>
>> Am I missing the point here, or is boot delegation not doing it's job?
>>
>
> I think the class loading hierarchy is like this:
>
> boot class loader<-extension class loader<-app class loader
>
yep, that's correct... the boot class loader won't see any extensions
> Boot delegation, by default delegates to the boot class loader. If you want
> it to use the extension class loader or the app class loader you need to set
> the following config property:
>
> org.osgi.framework.bundle.parent
>
> It can have one of the following values: boot, ext, app, or framework
> indicating the boot, extension, application, or framework class loader
> respectively.
>
> Try changing this value to "ext" or "app"...when you add packages to the
> system bundle, they are provided by delegating to the framework class loader
> which is typically the app class loader if you use the Felix launcher.
>
> -> richard
>
>
>
>> -- Rob
>>
>>
>> Ascert - Taking systems to the Edge
>> robw@ascert.com
>> +44 (0)20 7488 3470
>> www.ascert.com
>>
>>
Re: bootdelegation mystery
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 3/3/10 4:41, Rob Walker wrote:
> We've had a couple of instances where boot delegation just doesn't
> seem to work for us (we're on Felix trunk, but from a few weeks back).
>
> One was when doing profiling - the other just now with some crypto work.
>
> Our property is set as follows:
>
> org.osgi.framework.bootdelegation=sun.*,com.sun.*
>
> and the exception that gets thrown is:
>
> ERROR: EventDispatcher: Error during dispatch.
> (java.lang.NoClassDefFoundError: com/sun/crypto/provider/SunJCE)
> java.lang.NoClassDefFoundError: com/sun/crypto/provider/SunJCE
> at
>
> com.ascert.webui.vt.server.PreAuthScheme$Util.getScheme(PreAuthScheme.java:57)
>
> at com.ascert.webui.vt.GwtServlet.init(GwtServlet.java:443)
> at
> com.ascert.webui.vt.GwtServlet.activate(GwtServlet.java:359)
> at
>
> org.apache.felix.servicebinder.InstanceManager.validate(InstanceManager.java:273)
>
> at
>
> org.apache.felix.servicebinder.InstanceManager$DependencyManager.serviceChanged(InstanceManager.java:948)
>
> at
>
> org.apache.felix.framework.util.EventDispatcher.invokeServiceListenerCallback(EventDispatcher.java:878)
>
> at
>
> org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:732)
>
> at
>
> org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(EventDispatcher.java:662)
>
> at
> org.apache.felix.framework.Felix.fireServiceEvent(Felix.java:3601)
>
>
> I know for sure that class is available on the system classpath - it's
> part of the sunjce_provider.jar in JRE lib/ext.
>
> If I add a specific import for the package, I then get the usual
> unresolved constraint error:
>
> ERROR: Error starting file:c:\mnt\data\tas/lib/webui/webui.jar
> (org.osgi.framework.BundleException: Unresolved constraint in bundle
> com.ascert.webui.vt [40]: package; (package=com.sun.crypto.provider))
> org.osgi.framework.BundleException: Unresolved constraint in bundle
> com.ascert.webui.vt [40]: package; (package=com.sun.crypto.provider)
> at
> org.apache.felix.framework.Felix.resolveBundle(Felix.java:3277)
> at
> org.apache.felix.framework.Felix.startBundle(Felix.java:1611)
> at
> org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1082)
>
> Only by adding the package to the org.osgi.framework.system.packages
> list does the error then get cleared e.g.
>
> jre-1.6=
> ...
> org.xml.sax.ext; org.xml.sax.helpers; com.sun.crypto.provider;
> version="1.6.0"
>
> Whilst this gets around the error, unless I'm not understanding boot
> delegation it seems like a bug. I thought the point to boot delegation
> was to allow certain core Java classes, such as the sun.* and
> com.sun.* ones to be accessible without specific imports or being
> listed as system packages. Not graceful in an OSGi world, but
> sometimes the most practical solution for Sun suppler RT and ext
> classes .
>
> In our case, our bundle is a good citizen and does not use the
> com.sun.crypto.provider class in question here - we go via the
> javax.crypto API, and this is the one picking up the default
> com.sun.crypto.provider class.
>
> Am I missing the point here, or is boot delegation not doing it's job?
I think the class loading hierarchy is like this:
boot class loader<-extension class loader<-app class loader
Boot delegation, by default delegates to the boot class loader. If you
want it to use the extension class loader or the app class loader you
need to set the following config property:
org.osgi.framework.bundle.parent
It can have one of the following values: boot, ext, app, or framework
indicating the boot, extension, application, or framework class loader
respectively.
Try changing this value to "ext" or "app"...when you add packages to the
system bundle, they are provided by delegating to the framework class
loader which is typically the app class loader if you use the Felix
launcher.
-> richard
>
> -- Rob
>
>
> Ascert - Taking systems to the Edge
> robw@ascert.com
> +44 (0)20 7488 3470
> www.ascert.com
>
>