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. > > 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. > > 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 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. Patrick -- ________________________________________________________________ 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]>
