Henri,
GOMEZ Henri wrote:
> Yes bin/setclasspath.sh does many things and could be used.
>
> My advice it that the name is too generic and should be renamed
> when you install TC 3.x/4.x in a FHS way, ie execs in
> /usr/bin, datas in /var/tomcat4 or /usr/share/tomcat4.
>
> May be renamed to setcatalinacp.sh ?
I must admit that have all these *.sh files hanging around in the bin directory
annoys even me even though I created them. I have been thinking about (but never
enough time to implement) getting rid of these scripts entirely and replacing
them with a small Java class that does the following:
- The standard scripts, e.g. catalina.sh consist only of:
Resolve true location of $0 (existing code already does this)
Find java (almost any will do for this script)
java -classpath `basedir "$0"` \
org.apache.catalina.launcher.Launch "${@}"
- This new "Launch" class then can parse both the command line arguments and
a new properties file (e.g. conf/tomcat.properties) to figure out all of the
stuff that is currently in the scripts as environment variables (e.g.
classpath, JAVA_HOME, CATALINA_OPTS, System properties, etc. After parsing
all the command line arguments and properties (which are currently done by
the scripts), this "Launch" class would fork another Java process with the
real $JAVA_HOME that the user has configured with all of the applicable
classpath, System properties, and command line arguments.
So what advantage is there to this? Although there is no change in the
functionality of the scripts, it would solve some of the following problems:
1. Windows has many problems in its handling of environment variables such as
%0 is always meaningful, some versions don't allow an '=' in an environment
variable value (particularly vexing for Java programs), some versions have
limited environment space, the 'for' command cannot handle paths with spaces
in them, etc. Using the above method, I have made the "Launch" do the work
that the script is doing now.
Since Java has not problems with the above when values are put in properties
file, a lot of these Windows problems go away. More important, we would now
have a _platform_independent_ way to configure settings for Tomcat since
Java properties don't require quoting or other items that are different on
Windows and Unix (even paths can be represented in a platform independent
manner if we so choose).
2. If implemented properly, the "Launch" class can use any Java found in your
path to bootstrap itself (OK, I will need at least Java 1.1). I can use a
JRE or JDK. Since "Launch.class" would invoke the real Java that I want to
use based on a property in the "conf/tomcat" properties file, this means
that we can bootstrap ourselves enough to:
- Provide more meaningful error messages than we can do with shell script
"if" and "echo" statements, particularly on Windows
- Provide (someday) localized error messages
- Use your Java searching algorithm for the "Find a java" part of each
script. This will allow us to bootstrap Java without causing changes to
which Java Tomcat actually runs with (i.e. Christopher's concern).
3. Last, but not least, make the launching of Tomcat completely independent
of the user's environment variables. The 2 big advantages that I see are:
- System integration is easier where environment variables are difficult
to use (e.g. you can put an icon in the Windows
Start->Programs menus, you can start Tomcat from /etc/inittab, you
can make Tomcat an NT service, etc.)
- On Windows, we can log stdout and stderr to a log file (like it already
does on Unix) instead of printing the output to a MS-DOS window (it is
difficult to redirect stderr in Windows batch scripts)
Is something worth pursuing for Tomcat 4? I am willing to volunteer the effort.
Especially since it will make the Windows startup more in line with the Unix
startup. For the record, I prefer Unix (any flavor) over Windows. However, I
realize that making Tomcat work reliably on Windows is important as there are a
lot of Windows users of Tomcat out there.
>
> Excellent information that -Djava.endorsed.dirs. Could you give us an
> example of it if for example we want to use xerces-2.0.0 and xalan-2.3.0
> with Sun JDK 1.4.0-rc1 ?
>
In theory, with the current -Djava.endorsed.dirs setting, you could drop your
favorite xerces and xalan jars in common/endorsed (HEAD branch) or common/lib
(4.0.2 branch) and Tomcat will use those. Of course, you need to remove any
existing conflicting jars from those locations first and Tomcat may have
problems with some XML parser versions (i.e. bugs in Tomcat or the XML parser).
Patrick
>
> --
> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
--
_____________________________________________________________________
Patrick Luby Email: [EMAIL PROTECTED]
Sun Microsystems Phone: 408-276-7471
901 San Antonio Road, USCA14-303
Palo Alto, CA 94303-4900
_____________________________________________________________________
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
