on 2/7/01 6:05 PM, Craig R. McClanahan at [EMAIL PROTECTED]
wrote:
> For those interested in the gory details, the problem is in
> StandardClassLoader.findClass(), which delegates to the parent class
> loader prior to checking the local repositories (I'm not sure this is
> really correct behavior -- hence the need for some research). Consider
> a class like org.xml.sax.EntityResolver, which correctly exists in both
> Xerces and Crimson. If the Crimson version of this class is loaded
> first, any attempt to load other org.xml.sax.* classes from Xerces will
> fail with a package sealing exception, because crimson.jar is sealed.
By default, the behavior recommended by the docs -- and the one exhibited
here is correct for most cases as the classes that implement the same "name"
should be in totally different class loaders that are siblings and are not
in a parent-child relationship. The problem that you describe here is
symptomatic of some sort of parent-child relationship where differing
classloaders are resolving sometimes to the same classloader and sometimes
to different classloaders (often seen when there are subtle versioning
differences).
At least that's my two cents from having been around the class loader block
a few times.
.duncan
--
James Duncan Davidson
http://x180.net/ !try; do();
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
