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: [email protected] [mailto:[email protected]]
On Behalf Of Thomas Watson
Sent: Friday, June 05, 2009 3:52 PM
To: Equinox development mailing list
Subject: Re: [equinox-dev] FW: Classloader problem
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.
There is also a compatibility mode Equinox uses by default to delegate to the
parent (boot) class loader as a last resort if a class or resource cannot be
found by normal OSGi delegation. See osgi.compatibility.bootdelegation in
Eclipse help. If you set this configuration property to false then this last
resort delegation is disabled. But even with this compatibility mode enabled
you should be able to load org.apache classes from the installed bundles
instead of from the VM by default. If you think Equinox is configured correctly
in your environment then I suggest you open a bug against Equinox and give us
steps to reproduce. Thanks.
Tom
"O'Flynn, Dennis" ---06/05/2009 12:34:09 PM---Anyone have any experience
running Equinox using IBM J9? We are having some problems with using IBM J9
that we don’t encounte
From:
"O'Flynn, Dennis" <[email protected]>
To:
"Equinox development mailing list" <[email protected]>
Date:
06/05/2009 12:34 PM
Subject:
[equinox-dev] FW: Classloader problem
________________________________
Anyone have any experience running Equinox using IBM J9? We are having some
problems with using IBM J9 that we don’t encounter with Sun’s JVM.
See below…
The contents of this e-mail are intended for the named addressee only. It
contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose it
to anyone else. If you received it in error please notify us immediately and
then destroy it.
From: Hawkins, Joel
Sent: Friday, June 05, 2009 1:27 PM
To: O'Flynn, Dennis
Subject: Classloader problem
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
_______________________________________________
equinox-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/equinox-dev
<<image001.gif>>
<<image003.png>>
<<image004.png>>
_______________________________________________ equinox-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/equinox-dev
