geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick McGuire <>
Subject Re: Fixing java.endorsed.dirs
Date Fri, 29 Sep 2006 12:29:11 GMT
Matt Hogstrom wrote:
> 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.
That certainly makes sense.  That's exactly what happened when I removed 
the Xerces jars while trying to figure out why the yoko specs jar 
classes couldn't be resolved.  I was expecting the server to die an ugly 
death on startup and was shocked when it came up cleanly.

I've spent a lot of time googling on java.endorsed.dirs this morning, 
and I find an LOT of references for different projects (including Tomcat 
and JBoss) that have a requirement that the java.endorsed.dirs property 
be set on launch.  I found one discussion thread about solutions to get 
around the problem, and it appears forking a new process is the only 
alternative.  In this application's case, it had to unpack a jar file to 
create the endorsed directory, then launch a new process to run the main 
app.  Pretty ugly, but doable.  The launcher script seems like a good 
short-term solution.


> 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 <> 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
>>>> >> 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

View raw message