It would be more to cure curiosity :-) I think that upgrading xerces and xml-apis might be more important. G uses still xerces 2.6.2 which has a file date of feb 2004 in the historical part of the download area.
2.8.1 is the most recent. should I open a jira? On 9/28/06, Dain Sundstrom <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 >>
