On 9/8/16, 8:34 AM, Christopher Schultz wrote:
James, would you care to provide a (simple) patch? You'll get your
name in the changelog :)
Ok. In the initial comments for catalina.bat:
> . . .
rem Do not set the variables in this script. Instead put them into a script
rem setenv.bat in CATALINA_BASE/bin to keep your customizations separate.
rem
rem CATALINA_HOME May point at your Catalina "build" directory.
> . . .
becomes something like (and note the capitalization on the first line,
to make the warning stand out):
. . .
rem Do not set the variables in this script. Instead put them into a
script
rem setenv.bat in CATALINA_BASE/bin to keep your customizations separate.
rem
rem WHEN RUNNING TOMCAT AS A WINDOWS SERVICE:
rem Environment Variables for are NOT set in scripts, and any
rem attempt to set them in a setenv.bat script will be IGNORED.
rem Instead, they are set in the Registry, and are most conveniently
rem maintained with the "tomcat7w.exe" maintenance utility.
rem
rem CATALINA_HOME May point at your Catalina "build" directory.
. . .
And the corresponding addition should probably also be made to
catalina.sh, since *nix, Mac, and IBM Midrange users (all of whom would
be more familiar with catalina.sh) are probably the people most likely
to be unfamiliar with how things work on Windows, and to get caught by
this "gotcha."
FWIW, on an IBM Midrange box, I've found that the easiest way to launch
Tomcat is via a CL program (a sort of COMPILED script for the native
command language), that can look through the JVMs available, and select
the most appropriate one, and can also set the environment variables
(and even do it dynamically, from command-line parameters).
I welcome any rephrasing on my addition to the comment block.
--
James H. H. Lampert
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org