Thanks for the comments! I would agree with Jarek that two long-run java processes just for Geronimo service might not be a good idea. So I'll stick to the plain command method.
While waiting for my patches to be committed by the Commons community, for now I'll use the simple "stupid" command line option to start the Windows service, instead of the JVM or JAVA mode. The latter provides better configuration UI, while the command line method need the user to edit the long command line string if they want to change any argument (like JVM options). This way I minimize the code difference, as only one patch is necessary which fixes a real defect: https://issues.apache.org/jira/browse/DAEMON-118. Next I'll start to create the G plugin for this. We can update the contained EXE files when my patches are accepted by Commons Daemon project. -Jack 2008/12/5 Jarek Gawor <[EMAIL PROTECTED]> > On Thu, Dec 4, 2008 at 4:54 AM, Jack Cai <[EMAIL PROTECTED]> 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. > > That sucks, maybe somebody will eventually commit it. Or maybe we > should svn copy that code into Geronimo sandbox and maintain it here? > > > 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) > > Try putting all the geronimo-kernel, geronimo-system jars on the > system classpath and only create URLClassLoader with shutdown.jar or > server.jar (and delegating to the system classloader). > > Does Apache Commons Deamon restart the process automatically if if > detects abnormal shutdown? Personally, I'm against using GShell for > this as there is no need to start two Java processes just to run the > server. > > Jarek >
