On Sat, 03 Aug 2002 18:07:08 -0700, Patrick Luby wrote: > Costin, > > [EMAIL PROTECTED] 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) Main.java ? 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 worse. 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 catalina-launcher.sh 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. +1 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 :-) Costin > > Patrick > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
