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
[email protected]
+44 (0)20 7488 3470
www.ascert.com
--
Ascert - Taking systems to the Edge
[email protected]
+44 (0)20 7488 3470
www.ascert.com
