geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Heinz Drews" <>
Subject Re: Fixing java.endorsed.dirs
Date Thu, 28 Sep 2006 21:13:34 GMT
which class or interface has triggered the problem?
are part of the endorsed library mechanism.
Subpackages of org.w3c.dom are optional.

Other classes are part of regular class loading.

On 9/28/06, Dain Sundstrom <> wrote:
> On Sep 28, 2006, at 12:02 PM, Rick McGuire wrote:
> > Dain Sundstrom wrote:
> >> On Sep 28, 2006, at 11:19 AM, Heinz Drews wrote:
> >>
> >>> There was sometime ago a discussion thread about the requirement to
> >>> have the jars in endorsed dirs also on the classpath.
> >>>
> >>> If endorsed would have been picked up then this would not be
> >>> necessary.
> >>>
> >>> It is still possible to get xerces as the parser because of
> >>> including
> >>> it on the classpath.
> >>> It would not be the default using the factories.
> >>
> >> Yep.  In Geronimo, we use the default factories.  Additionally,
> >> the J2EE spec requires that the default factories return a newer
> >> parser version then is included in a 1.4 vm, so you should have a
> >> fairly high confidence there are tests to for it in the TCK.
> >
> > The problem here is not the resolving of the class factory, but
> > rather the resolution of the org.w3c.dom classes.  Those are the
> > ones that are a potential trouble spot.  If the JVM native versions
> > are not compatible with the Xerces ones, this can manifest as a
> > NoMethodFoundException.  But only if you happen to hit code that
> > attempts to call one of the missing classes.  This is something of
> > a ticking time bomb.
> > I had a similar situation with Yoko.  I had no problems loading the
> > Yoko ORB classes.  The yoko-core jar file doesn't even need to be
> > in the endorsed dir to work.  However, there was a issue with one
> > of the org.omg classes.  The Sun version wasn't compatible with the
> > CORBA spec, so if you tried to run the Yoko code using the native
> > org.omg classes, you got a NoMethodFoundException.  Once I
> > successfully got the JVM to process this jar as part of the
> > endorsed dirs, I was able to override the native classes and the
> > Yoko ORB started working.
> This is weird.  I tried to write some demo code to show that you can
> override after the vm started and failed :(  What is particular
> strange is we had a customer problem exactly as you describe above
> except backwards.  The customer was using java5 and when they loaded
> a dom they were getting an old version of the dom apis included with
> Geronimo.  We fixed this problem by deleting the xerces jars from the
> endorsed dir.
> Anyway, this sucks, since it requires users to use a shell script to
> launch Geronimo.  Is there anyway to detect the corba api version and
> not load the Yoko classes that have the problems?
> -dain

View raw message