tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: [5] launcher/deamon
Date Sun, 04 Aug 2002 00:24:14 GMT
On Sat, 3 Aug 2002, Patrick Luby wrote:

> Basically, commons-launcher classloads the ant.jar bundled with Tomcat 5 
> (Jasper2 also classloads Ant 1.5). commons-launcher is just a wrapper 
> for bootstrapping Ant plus some custom tasks and data types. I don't use 
> Ant's scripts because Ant' batch script suffers the same Windows 
> problems as every other batch based program:

There are 2 issuses here:

- how you run the program - I assume you need a .bat or something to
run java with the right parameters. It can be just "java -jar", but
you still need that. 

- extensions to ant's Exec ( to detach, etc ). I think those should 
be contributed to ant, and only if they refuse them keep them in
tomcat. Same for the startup script. 

> I mentioned the "community" because Bill Barker voiced some reservations 
> about including commons-launcher.

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

> This was included in Remy's Tomcat 5 proposal. It was under an item, 
> IIRC, entitled "Tomcat 5 will use the Launcher used in Sun's JWSDP 
> product". Since the Tomcat 5 proposal got approved, I assumed it was my 

That assumes that everyone knows how JWSDP works :-) 

Even if this was included in Remy's proposal - it seems many people
are not very aware of this.

> > I partially agree - the scripts are well tuned and work, so there's no
> >  reason to drop them. 
> They work fine on Unix. On Windows, they work fine *if* you:
> 1. Always define %CATALINA_HOME% (%0 is not always reliable)
> 2. You don't have spaces in %CATALINA_HOME% ("for" loops do not work
>     with spaces on some Windows versions)
> 3. You don't use any of the %JAVA_OPTS% or %CATALINA_OPTS% environment
>     varables (batch scripts on some versions of Windows will abort if
>     there are "=" characters in the environment variable)
> 4. You don't want stderr to be logged to a file (stderr cannot be
>     redirected in a DOS shell)

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. 

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

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.

> The vote to put it in was already made in the Tomcat 5 proposal. So I 
> think voting on it again is redundant. If someone would like to propose 
> its removal, I am OK with that and I can even do the removal for them.

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.

> Unfortunately, I really don't have much spare time available right now 
> to push for acceptance of this new piece of code. So, if anyone is 
> really uncomfortable with this code or they don't think it is ready for 
> use in Tomcat yet, I will have no hurt feelings if we want it to be 
> taken out. In fact, I would find that understandable since I have not 
> been able to find the time to write up the documentation for the tool.

Nobody has time. 

I would say it's best to leave it in - as an optional component ( and
just change build.xml to detect if it is available ). 

When you or anyone finds the time to document it and get launcher 
released or merged into ant - we can discuss making it the 'default' 
startup. But I will opose making it the 'only' startup mechanism.


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

View raw message