On 3 March 2010 20:30, Richard S. Hall <[email protected]> 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 >> [email protected] >> +44 (0)20 7488 3470 >> www.ascert.com >> >>
