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