[5] launcher/deamon
Patrick ( and all ), The 'launcher' is a very good idea - reducing the use of .bat/sh and having 'keepalive' functionality and a clean startup file are all great. My only requirement is to keep the code clean and minimise dependencies. My understanding of the launcher is that it uses ant file to describe the paths, conditions, etc. I looked at the code in sandbox - and there are few issues ( many tasks that duplicate existing functionality in ant, etc ), and some should be contributed back to ant ( like the enhancements to Execute ). I support the idea - as long as tomcat code is kept clean and this is optional. Right now we have a mess of launchers / entry points. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5] launcher/deamon
Costin, I plan to post a patch to Ant for the enhanced data types (e.g. syspropertyset) and the conditional java task elements (e.g. sysproperty with if and unless attributes) back to Ant as I think they would really enhance the Ant java task. I just haven't had time yet but I will do so eventually. As for making the launcher functionality optional, I am OK with whatever the community wants. But before the community takes it out, let me explain why we put it in the first place: 1. Make Tomcat 5 startup reliably on Windows (Windows batch scripts are notoriously flaky). 2. Emulate the Unix startup on Windows (Windows has no background operator like Unix and you cannot redirect stderr to an output file) 3. Run background applications (like Tomcat 5 or GUI applications) without a DOS shell on Windows. 4. Eliminate maintainance of 2 sets of scripts (one set for Windows and one set for Unix). From the above list of features, you probably have noticed that the launcher does not add any new features for Unix platforms but really adds a lot of fit and finish to Tomcat on Windows. So, I think the basic trade-off with using the launcher vs. scripts is that with the launcher you get a more native looking application on Windows at the price of losing the simplicity of scripts and adding one more dependency to the build. My recommendation for the community would be to either use the launcher or use scripts and not try to accomodate both. I believe that keeping the old scripts *and* the launcher would cause a lot more maintenance and a more confusion among users. If the community chooses not to use the launcher, feel free to remove it from the Tomcat 5 build and restore the old scripts. Patrick Costin Manolache wrote: Patrick ( and all ), The 'launcher' is a very good idea - reducing the use of .bat/sh and having 'keepalive' functionality and a clean startup file are all great. My only requirement is to keep the code clean and minimise dependencies. My understanding of the launcher is that it uses ant file to describe the paths, conditions, etc. I looked at the code in sandbox - and there are few issues ( many tasks that duplicate existing functionality in ant, etc ), and some should be contributed back to ant ( like the enhancements to Execute ). I support the idea - as long as tomcat code is kept clean and this is optional. Right now we have a mess of launchers / entry points. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- 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]
Re: [5] launcher/deamon
Patrick, the idea is great - the implementations details are a bit problematic :-) On Sat, 03 Aug 2002 09:04:18 -0700, Patrick Luby wrote: Costin, I plan to post a patch to Ant for the enhanced data types (e.g. syspropertyset) and the conditional java task elements (e.g. sysproperty with if and unless attributes) back to Ant as I think they would really enhance the Ant java task. I just haven't had time yet but I will do so eventually. I saw a proposal for 'conditional' on all tasks ( for ant1.6). In any case the current ant ( even 1.5 ) seems to have all the elements it needs to start tomcat ( cactus and anteater are doing it ). As for making the launcher functionality optional, I am OK with whatever the community wants. But before the community takes it out, let me I don't think the 'community' wants something - and I must admit I had very little idea of this going on. If _you_ think this is a good idea - you must make a more explicit proposal, make sure everyone is aware of this, eventually have a vote and add some documentation ( a spec / the proposal / whatever ). I think it is an excelent idea and I would love to see it happen - but I don't like the implementation details I'm seeing so far. Depending on commons-sandbox and reinventing things that are already in ant, or doing things slightly differently than ant is doing is not very good. You can add the tasks that you need in tomcat, and 'antlib' is very likely to happen for ant1.6 ( the current feeling is that ant optional tasks should be split ). 1. Make Tomcat 5 startup reliably on Windows (Windows batch scripts are notoriously flaky). 2. Emulate the Unix startup on Windows (Windows has no background operator like Unix and you cannot redirect stderr to an output file) 3. Run background applications (like Tomcat 5 or GUI applications) without a DOS shell on Windows. 4. Eliminate maintainance of 2 sets of scripts (one set for Windows and one set for Unix). And also: 5. make tomcat startup easy to automate from ant ( all the test frameworks will benefit ) 6. use a well-known format ( path, etc ) to describe the env. 7. reuse open-source code instead of reinventing the wheel ( ant ). 8. Add extra features - like multiple profiles ( using different targets ), ability to easily execute 'pre/post' tasks ( like generating the apache config files ) And I can go on - there are many other benefits. Nobody is arguing ( at least not me ) on the benefits of the idea. From the above list of features, you probably have noticed that the launcher does not add any new features for Unix platforms but really adds a lot of fit and finish to Tomcat on Windows. I think it adds quite a bit on both unix and windows. So, I think the basic trade-off with using the launcher vs. scripts is that with the launcher you get a more native looking application on Windows at the price of losing the simplicity of scripts and adding one more dependency to the build. I disagree ( twice )- the bat scripts are not simple, and you _don't_ have to add dependencies to the build. My recommendation for the community would be to either use the launcher or use scripts and not try to accomodate both. I believe that keeping the old scripts *and* the launcher would cause a lot more maintenance and a more confusion among users. I partially agree - the scripts are well tuned and work, so there's no reason to drop them. At least in 3.3 we did a lot of simplifications - like 'guessing' tomcat.home, etc - so a lot of stuff can be removed. If the community chooses not to use the launcher, feel free to remove it from the Tomcat 5 build and restore the old scripts. I'm not the 'community' - but I agree with 'choosing' :-) Make a proposal, have a vote - that's the only way to know what the community chooses. Costin Patrick Costin Manolache wrote: Patrick ( and all ), The 'launcher' is a very good idea - reducing the use of .bat/sh and having 'keepalive' functionality and a clean startup file are all great. My only requirement is to keep the code clean and minimise dependencies. My understanding of the launcher is that it uses ant file to describe the paths, conditions, etc. I looked at the code in sandbox - and there are few issues ( many tasks that duplicate existing functionality in ant, etc ), and some should be contributed back to ant ( like the enhancements to Execute ). I support the idea - as long as tomcat code is kept clean and this is optional. Right now we have a mess of launchers / entry points. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5] launcher/deamon
Costin, Costin Manolache wrote: I saw a proposal for 'conditional' on all tasks ( for ant1.6). In any case the current ant ( even 1.5 ) seems to have all the elements it needs to start tomcat ( cactus and anteater are doing it ). 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: 1. You can't run the application in the background (Ant's java task does a Process.waitFor() on all forks) 2. Ant must be launched with a DOS batch script that is subject to the same DOS shell flakiness as the old Tomcat scripts had (e.g. %0 sometimes does not contain a path, the for command sometimes cannot handle spaces in paths, environment variables cannot handle = characters in them, etc.) 3. Ant cannot be detached from a DOS shell I did not want to reinvent Ant. I merely wanted to use its XML structure. In essence, like Jasper2, I am embedding Ant in my tool. Isn't this what code reuse is all about? As for making the launcher functionality optional, I am OK with whatever the community wants. But before the community takes it out, let me I don't think the 'community' wants something - and I must admit I had very little idea of this going on. I mentioned the community because Bill Barker voiced some reservations about including commons-launcher. If _you_ think this is a good idea - you must make a more explicit proposal, make sure everyone is aware of this, eventually have a vote and add some documentation ( a spec / the proposal / whatever ). 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 responsibility to put the Launcher into Tomcat 5. I generally don't try to push features into Tomcat as I have very little spare time. I think it is an excelent idea and I would love to see it happen - but I don't like the implementation details I'm seeing so far. Depending on commons-sandbox and reinventing things that are already in ant, or doing things slightly differently than ant is doing is not very good. Again, I am not reinventing Ant. I am using Ant's functionality only as an embedded library. In fact, in the Sun JWSDP product, its Launcher did not use Ant at all and focused only on fixing the DOS problems and running with a DOS shell. The use of Ant was a nice way to expose the scripting of the tool instead of burying the scripting in Java code. You can add the tasks that you need in tomcat, and 'antlib' is very likely to happen for ant1.6 ( the current feeling is that ant optional tasks should be split ). 1. Make Tomcat 5 startup reliably on Windows (Windows batch scripts are notoriously flaky). 2. Emulate the Unix startup on Windows (Windows has no background operator like Unix and you cannot redirect stderr to an output file) 3. Run background applications (like Tomcat 5 or GUI applications) without a DOS shell on Windows. 4. Eliminate maintainance of 2 sets of scripts (one set for Windows and one set for Unix). And also: 5. make tomcat startup easy to automate from ant ( all the test frameworks will benefit ) 6. use a well-known format ( path, etc ) to describe the env. 7. reuse open-source code instead of reinventing the wheel ( ant ). 8. Add extra features - like multiple profiles ( using different targets ), ability to easily execute 'pre/post' tasks ( like generating the apache config files ) And I can go on - there are many other benefits. Nobody is arguing ( at least not me ) on the benefits of the idea. From the above list of features, you probably have noticed that the launcher does not add any new features for Unix platforms but really adds a lot of fit and finish to Tomcat on Windows. I think it adds quite a bit on both unix and windows. So, I think the basic trade-off with using the launcher vs. scripts is that with the launcher you get a more native looking application on Windows at the price of losing the simplicity of scripts and adding one more dependency to the build. I disagree ( twice )- the bat scripts are not simple, and you _don't_ have to add dependencies to the build. My recommendation for the community would be to either use the launcher or use scripts and not try to accomodate both. I believe that keeping the old scripts *and* the launcher would cause a lot more maintenance and a more confusion among users. 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
Re: [5] launcher/deamon
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) 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. 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. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5] launcher/deamon
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]
Re: [5] launcher/deamon
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
