geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Heinz Drews" <heinz.dr...@gmail.com>
Subject Re: Fixing java.endorsed.dirs
Date Fri, 29 Sep 2006 00:27:50 GMT
It would be more to cure curiosity :-)

I think that upgrading xerces and xml-apis might be more important.
G uses still xerces 2.6.2 which has a file date of feb 2004 in the
historical part of the download area.

2.8.1 is the most recent.  should I open a jira?


On 9/28/06, Dain Sundstrom <dain@iq80.com> wrote:
> Sorry, but I don't remember.  Matt presented the problem to me, I
> suggested removing the jars from the endorsed dir, and the problem
> went away.  If you are really interested, I'll volunteer Matt to find
> out the exact class :)
>
> -dain
>
> On Sep 28, 2006, at 2:13 PM, Heinz Drews wrote:
>
> > Dain,
> > which class or interface has triggered the problem?
> > Only
> > org.w3c.dom
> > org.xml.sax
> > org.xml.sax.ext
> > org.xml.sax.helpers
> > 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 <dain@iq80.com> 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
> >>
>
>

Mime
View raw message