As I discovered yesterday, the Geronimo use of java.endorsed.dirs is
completely broken. There's code in
org.apache.geronimo.system.main.Daemon that appends information from the
Geronimo manifest file to the system properties java.endorsed.dirs and
java.ext.dirs, with the expectation that those directories will get used
for class resolution. Well, unfortunately, those two properties are
only used by the JVM during JVM initialization to set up the initial
class loading structure. Once the code in Daemon is reached, it's too
late.
It's fairly simple to modify geronimo.bat and geronimo.sh to set these
properties to hard coded values. For example, this seems an appropriate
value for java.endorsed.dirs
-Djava.endorsed.dirs="$JRE_HOME/lib/endorsed:$GERONIMO_BASE%/lib/endorsed" \
using the jre's endorsed directory and adding on the Geronimo endorsed
directory. A similar thing can be done for java.ext.dirs, although the
Geronimo assemblies don't even create the directory reference in the
manifest. These are just hard-coded values. It's fairly difficult to
process the manifest file from a batch file, but since these directories
are hard coded into the build, I suspect it's ok to hard code them into
the launcher scripts.
I should be possible to accomplish what Daemon is doing by forking a new
process to run the actual server, but I'm not sure that's really a good
idea.
So, that's the basics. Right now, I'm working on fixing up the scripts
and removing the non-function property setting from Daemon. Does this
seem like the correct approach?
Rick
- Fixing java.endorsed.dirs Rick McGuire
-
