geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jack Cai" <greensi...@gmail.com>
Subject [discussion] Using Apache Commons Deamon to run Geronimo as a Windows service
Date Thu, 04 Dec 2008 09:54:12 GMT
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

Mime
View raw message