geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <d...@iq80.com>
Subject Re: Fixing java.endorsed.dirs
Date Thu, 28 Sep 2006 21:29:27 GMT
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