| RE: [equinox-dev] FW: Classloader problem |
|
Hi Tom, We've been experimenting with the following properties: osgi.compatibility.bootdelegation=false org.osgi.framework.bootdelegation=\ com.ibm.jsse2, \ com.ibm.jvm, \ com.ibm.lang.management, \ com.ibm.misc, \ com.ibm.nio.cs, \ com.ibm.oti.*, \ com.ibm.security.*, \ com.sun.jmx.*, \ javax.crypto, \ javax.crypto.spec, \ javax.management, \ javax.management.*, \ javax.naming, \ javax.naming.*, \ javax.net.ssl, \ javax.security.*, \ javax.sql, \ javax.swing, \ javax.swing.*, \ sun.awt, \ sun.beans.editors, \ sun.io, \ sun.management.*, \ sun.misc, \ sun.net, \ sun.net.*, \ sun.nio.*, \ sun.reflect, \ sun.reflect.*, \ sun.rmi.*, \ sun.security.*, \ sun.text, \ sun.text.resources, \ sun.util.* We've omitted the following from the list: javax.xml javax.xml.* org.w3c.dom org.xml.sax org.xml.sax.helpers We had hoped to have our bundles use the XML bundles present in our
stack. We include the Orbit jar javax.xml_1.3.4.v200801282000.jar which
exports javax.xml.*, org.w3c.dom.* and the SAX packages. When we include this
restriction to the classloading, we find our collection of bundles will not
start (although Equinox does), be it on J9 or the Sun VM. For example, we are using PAX Logging bundles which include Log4J.
Log4J code wants to parse its XML configuration files, yet the bundle it is in
does not import any of the XML packages. Our thinking is that it is receiving
these XML packages implicitly through boot classloader delegation. When this
restriction is lifted (the default condition) the bundle works fine and is able
to start and parse its configuration files. In J9, however, we have other
bundles that refuse to work when the XML packages are permitted to come from boot
classloader delegation. While we believe this is now a development issue on our part (fix
our manifests), do our conclusions hold water? Is there something else we ought
to try? Additionally, is there something in the Eclipse IDE we can do to
have it warn us when our bundles get their XML goodies from the JRE instead of
other bundles? Regards, Michael Murphree Compuware Corporation From:
equinox-dev-bounces@xxxxxxxxxxx [mailto:equinox-dev-bounces@xxxxxxxxxxx] On
Behalf Of Thomas Watson Are you setting the configuration property
"org.osgi.framework.bootdelegation=*"? What version of Equinox do you
use? Anything version 3.3 or later should not be delegating class loads to the
VM first by default (unless you set explicitly set
org.osgi.framework.bootdelegation=*). If you use Import-Package for some
org.apache.* package and you get resolved to an export from a bundle then you
should load the content of the package from that bundle.
See
below…
Dennis - In a nutshell - The J9 VM
packages many javax xml extension jars and their corresponding apache
implementations in the library directory of the JRE. Many of the same packages
are supplied by bundles that ship with Eclipse. A number of these bundles
export packages without version numbers, and we find ourselves running into
class verification errors when the classes provided by the JRE don't match
those expected by the bundles. The Sun JVM prepend the apache classes with
com.sun., so the problem is partially mitigated. However, for javax.* classes,
the potential for trouble remains. Is there a way to alter the
contents of the system classpath during osgi startup such that we can suppress
these additional classes provided by J9 and resolve them from the bundles
provided by Eclipse? Cheers, Joel _______________________________________________ |
