Tomcat 5's service.bat, etc.

[Jess Holle <je...@ptc.com>]

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.
   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.
   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.
   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.

Personally, JavaService and an Ant script to produce the right 
(enormous) command line for seem to do the trick nicely -- with Tomcat 
4.1.x and 5.0.x.

--
Jess Holle

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

[Jess Holle <je...@ptc.com>]

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

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

[Bill Barker <wb...@wilshire.com>]

----- Original Message -----
From: "Jess Holle" <je...@ptc.com>
To: "Tomcat Developers List" <to...@jakarta.apache.org>
Sent: Wednesday, March 24, 2004 11:18 AM
Subject: Tomcat 5's service.bat, etc.


> 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 :).

>    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.

>    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 ;-).

>    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.
>
> Personally, JavaService and an Ant script to produce the right
> (enormous) command line for seem to do the trick nicely -- with Tomcat
> 4.1.x and 5.0.x.
>

Whatever makes you happy ;-).

> --
> Jess Holle
>
>