I would assume that using a command line parm provides greater flexibility than extracting it from a manifest. Even if we would use the approach to spawn a new JVM.
Heinz On 9/28/06, Rick McGuire <[EMAIL PROTECTED]> wrote:
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
