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 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.
As did I. It took me a long time to figure out what was wrong because I
was assuming that the Geronimo code I was looking at "had to be
working". Once I wrote some simpler test cases, I discovered it wasn't,
and experiments I ran inside of Geronimo confirmed this. And based on
my understanding of class loading (which is pretty good, considering I
used to be responsible for the class loading code in the IBM JVM), I was
surprised to see that technique being used. java.endorsed.dirs was a
feature that came in after I no longer worked on the JVM, but
bootclasspath processing has always been "locked down" very early in JVM
startup.
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?
The problem is not in loading Yoko classes, but in getting the Yoko
classes to load in the first place. The presence of the org.omg classes
on the bootclasspath are the source of the problem. java.endorsed.dirs
is the established way to push the JVM native versions to one side and
replace them with a newer version.
Rick
-dain
