tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patrick Luby <>
Subject Re: [5] launcher/deamon
Date Sun, 04 Aug 2002 01:07:08 GMT
Costin, wrote:
> On Sat, 3 Aug 2002, Patrick Luby wrote:

> I also have reservations - I see no reason to require it, at least 
> not until commons-launcher is stable and released. 
> "java -jar tomcat.jar"  should be enough ( I almost got it working
> for 5.0, and it works very well for 3.3 ). 

java -jar has one big problem: how do you set java.endorsed.dirs? This 
java.endorsed.dirs problem is one of the primary reasons the Launcher 
forks a child JVM. Since java.endorsed.dirs must be set when you invoke 
the JVM (setting in main() has no effect), you need to use the 
-Djava.endorsed.dirs=... command line argument with JDK 1.4. And since 
setting java.endorsed.dirs in a batch script proved flaky due to the %0 
problem in some Windows versions, I had to fork a child JVM.

If you find a way around this without forking, let me know because the 
one thing I don't like about my Launcher implementation is the need to 
fork a child JVM.

> Have you looked at tomcat(3) ? It works the same on 
> windows and unix, and all it needs is 'java -jar'. All logic
> to find TOMCAT_HOME is in java. 

See my JDK 1.4 and java.endorsed.dirs issue above. The java -jar works 
great on JDK 1.2 and JDK 1.3, but not JDK 1.4 when you need a custom
XML parser and, unfortunately, the default JDK 1.4 parser does not have 
the XML schema support that Tomcat 5 needs so we need to set 

> Of course, passing JAVA_OPTS is a different story - and I'm not sure
> running a java program to set the options and run another program
> is a good solution ( the startup time will be pretty big - it 
> is already too big for my taste ).

A more efficient solution is a native program that uses the Java 
Invocation API to load the JVM and run the target application's main(). 
I did not go that route only because I did not want to put native C code 
into Tomcat. But that might be the best course of action in the long run.

> So I think having multiple options is good - the service wrapper ( C ),
> the BAT, eventually a small C wrapper, ANT/fork, ANT/in-process.
> If we add most logic inside the starter ( creating CLASSATH, detect
> TOMCAT_HOME, etc ) the external starter can be simple enough.

Makes sense.

> I was sugesting 'vote' more as a way to get more people aware of this.
> As I mentioned, I didn't know that the launcher will be required or 
> the BATs will no longer be used. And I suspect other people were 
> in the same situation.
> If not a vote - at least a spec describing the 5.0 startup mechansim(s),
> checked into CVS. 
> The problem is not on removing the launcher, but on making sure  
> other mechanisms are still possible and we keep it optional at 
> least until commons-launcher has a 1.0 release, enough documentation
> and stability

How about this: I revert the build back to the old scripts and those 
scripts are copied into the distribution's bin directory. Then, if 
commons-launcher is available, the new scripts (with a different name 
such as so that old scripts don't get overwritten) 
and commons-launcher also get copied into the distribution's bin directory.

This way, people can try it out and suggest improvements if they want 
to, but the old scripts will still be the default.

This switch won't take much time to make.


Patrick Luby                     Email:
Sun Microsystems                         Phone: 408-276-7471
901 San Antonio Road, USCA14-303
Palo Alto, CA 94303-4900

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message