tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jess Holle <je...@ptc.com>
Subject Re: Tomcat 5's service.bat, etc.
Date Wed, 24 Mar 2004 22:13:43 GMT
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



Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message