tomcat-dev mailing list archives

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

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

First of all, there is no need to do that for 1.3, and that's what most
people are using.

Second, endorsed.dirs is a problem only if you want to replace the javax.
or org.xml/w3c packages. And it's a stupid thing - I think we can get
over it, there are far too many problems.

We can still use a different parser/xslt if needed. 

Unfortunately the endorsed.dirs ( and requiring this in command line )
is stupid, and can't be fixed. Hopefully 1.4.2 or other VMs will fix
this - if not we should just live with it. 

>> 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
> java.endorsed.dirs.

Again, AFAIK you don't need endorsed to use a different parser.

And 'schema support' is needed only for validation - and hopefully 
we stop the stupid practice of validating the same file every time
we start tomcat, even if it is not modified. 

In 3.3 we save a timestamp when we validate and save more 1/2 of 
the startup time for a webapp. With schema validation it'll be much 

If the user really wants the web.xml validated by a schema ( which
IMHO is plain stupid - tomcat is going to process every piece 
of information from it anyway ) - we can just spawn a java process
with the right endorsed.dirs for validation. After all this will be
nothing compared with the overhead of schema validation.

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


Why do people believe you need Invocation or some other fancy
things? A fork()/exec() is enough if you only want a replacement for
a .bat file.

Tomcat does use native code already - the service stuff on windows and
the jk code. The jk code can also be used for chuid() - quite important
in some cases.

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


As I said, I like the idea of using an ant xml file for the startup 
process - and we need to support starting/stoping tomcat from ant anyway.

Projects like anteater/cactus need that ( anteater even more as it's
intercepting the requests - so it must be in-process ).

BTW, to eat our dog food - we should use the ant tasks in our test as 
well, when it works :-)


> Patrick

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

View raw message