Why not use GShell here? ie. just put lib/boot/gshell-bootstrap.jar
on your classpath?
--jason
On Dec 4, 2008, at 4:54 PM, Jack Cai wrote:
I have been working on enabling Geronimo to run as a Windows service
using Apache Commons Deamon procrun utility. I have been making good
progress. Now I have some problems and would like to hear your
opinions.
1. I have gone through all the open JIRAs of that project and are
fixing some of them. I have also reported and fixed several found by
myself, and a few improvements too. But nobody is helping to commit
my patches. Will it be OK that Geronimo just use the binary code
built by me without maintaining the latest code (I mean, which
includes my patches)? Tomcat only include procrun's binary today (as
tomcat6.exe and tomcat6w.exe) which is probably built with the
latest code from Apache Commons.
2. Currently procrun need the starter class and stopper class to be
on the same classpath. Unfortunately our server.jar and shutdown.jar
contains different config.ser, which screws things up. So I tried
various ways to work around this problem before I change procrun's
design -
A. write a wrapper, which use a URLClassloader to load different
jar for startup and shutdown. To do so, I had to first remove the
jpa agent, as the system classloader (parent of my URLClassloader)
will load the config.ser in jpa.jar. After that Geronimo starts to
boot, until the below exception occurs:
17:43:19,421 WARN [1/car,j2eeType=GBean,name=JMXService] Failure in
JMXConnector service:jmx:rmi://0.0.0.0:9999/jndi/rmi://0.0.0.0:1099/
JMXConnector
17:43:19,421 ERROR [GBeanInstanceState] Error while starting; GBean
is now in the FAILED state:
abstractName="org.apache.geronimo.framework/j2ee-security/2.1.1/car?
ServiceModule=org.apache.geronimo.framework/j2ee-security/2.1.1/
car,j2eeType=GBean,name=JMXService"
java.lang.NoClassDefFoundError:
org.apache.geronimo.kernel.rmi.RMIClassLoaderSpiImpl
at
java
.rmi.server.RMIClassLoader.initializeProvider(RMIClassLoader.java:680)
B. so I rewrite the wrapper and use (dirty) reflections to add jar
file to system classloader's classpath based on the action (start/
stop). Sadly, the jpa.jar again gets into the way. Obviously the
jpa.jar is searched before the newly added jar. If I remove the jpa
agent, then things go smoothly. I could do more hack with the
classloader to work around the jpa.jar. But this hacking does not
sound right to me in the first place.
C. Use procrun's jvm mode (instead of java command line), and only
put server.jar in classpath. Write a simple class which calls
"System.exit(0)" for stopping Geronimo. This works, but only that
procrun does not clean up properly.
Are there other better options? Appreciate your help!
-Jack Cai
