geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Hogstrom <m...@hogstrom.org>
Subject Re: Fixing java.endorsed.dirs
Date Fri, 29 Sep 2006 12:02:45 GMT
I'm not sure it went away.  IIRC this was a few months ago.  I'll  
have to go back to the dark recess of my mind but the experimentation  
was more around did the VM  fall over if we removed the files from  
endorsed and it did not.  Its possible that the reason is it never   
worked from the beginning.
On Sep 28, 2006, at 5:29 PM, Dain Sundstrom 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
>>>
>
>
>

Matt Hogstrom
matt@hogstrom.org




Mime
View raw message