Re: Tomcat 5's service.bat, etc.

[Jess Holle]

Bill Barker wrote:

The service.bat and tomcat.exe in Tomcat 5 have a number of issues as I
see it:
  1. The new tomcat.exe (aka procrun) does not seem to reliably route
     stdout and stderr to the specified files.
         * Compare JavaService (aka Tomcat 4.1.x's tomcat.exe) stdout
           and stderr treatment to procrun's.  JavaService captures all
           the startup stdout as well as System.out.println's, etc.
           procrun does not.
   

Procrun works fine with --Java=java.  Yes, it needs work
for --Java=c:\path\to\jvm.dll (known issue, with outstanding BZ entry :).
 

Hmmm....

--Java=pathToJvmDll did not work at all for me -- service failed to 
install and other errors.  [W2K with latest service packs and Java 2 
v1.4.2_04.]

--Java=java worked but lost most of the stdout and stderr output -- 
including all the startup output.  It did seem to start up faster than 
JavaService...

  2. Tomcat 5 does not include any documentation on how to use procrun
     (or even that tomcat.exe is procrun).
  3. I have not managed to get procrun to target the "server" JVM (as
     opposed to the client) in any reliable fashion.
         * With JavaService this was achieved by targeting the
           appropriate jvm.dll.  The procrun docs say the same thing is
           possible, but this does not work.
   

This works fine for me with either --Java=java -JavaOptions=-server#... or
with --Java=c:\path\to\server\jvm.dll.
 

I was actually referring to the latter approach, which as I said did not 
work for me.

I did not honestly trust the first approach -- I guess I should have....

  4. service.bat does not route as many arguments to procrun as what I
     for one route to JavaService -- and thus it provides less
     flexibility (especially with no documentation).
         * For JavaService I provide heap sizing, etc, parameters, as
           this is critical to any real use of Tomcat.
         * Having built in support for passing JPDA debug args to the
           JVM is also a must.
   

So edit the service.bat file :).  As usual, patches are always welcome ;-).
 

The fact that you have to replace all spaces with #'s and shovel all 
JAVA_OPTS or CATALINA_OPTS into a single argument makes it more 
difficult to just pass in and concatenate portions of the command line.

With JavaService, one can do:

   set javaMemArgs=...
   set debugArgs=...
   set javaPropArgs=...
   set javaArgs=%javaMemArgs% %debugArgs% %javaPropArgs%
   JavaService.exe -install %serviceName% %jvmDllArg% %javaArgs%
   %startArgs% %stopArgs% %stdioArgs% %currDirArgs% 

In other words, one can flexibly and easily insert additional 
arguments.  With procrun, I have to worry about replacing some spaces 
with #'s, properly escaping quotes, etc, within the aggregate argument 
containing all the Java arguments, etc.

Essentially this makes it harder to have a one-size fits (most) all script.

  5. service.bat does not provide any default handling of tools.jar.
         * By default the resulting service can't compile JSP pages.
Overall, service.bat and procrun feel like they're not ready for
production use -- which is fine as long as that's understood by the user
community.
   

I should clarify that another reason for this was a number of crashes I 
had just installing and removing my service with procrun.

--
Jess Holle