Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Mime-Version: 1.0 (Apple Message framework v752.2)
In-Reply-To: <4369f0ce0609281413h3364d6f6p7161ffec6014acb6@mail.gmail.com>
References: <451BA191.5070105@gmail.com>
 <245387A4-CF1E-4267-B190-BBF72892D46A@iq80.com>
 <4369f0ce0609281119o3c2cd611ge064d96671e0353e@mail.gmail.com>
 <33272A99-EB8A-4E8A-AFAE-0E67280A3245@iq80.com> <451C1C2F.6080108@gmail.com>
 <433689EA-8653-4EDF-B278-A2AF780B0375@iq80.com>
 <4369f0ce0609281413h3364d6f6p7161ffec6014acb6@mail.gmail.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <922064D1-6B88-4FFD-BEF2-C1F8097D3D53@iq80.com>
Content-Transfer-Encoding: 7bit
From: Dain Sundstrom <dain@iq80.com>
Subject: Re: Fixing java.endorsed.dirs
Date: Thu, 28 Sep 2006 14:29:27 -0700
To: dev@geronimo.apache.org

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