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