I guess one of the important questions -- and maybe this is what you meant by a service -- is should Geronimo be launched in the background or left running for Ctrl-C. The Tomcat builds I've used semi-recently seem to kick it off in the background. I kind of prefer the foreground during development, and background for servers. It would be extra nice just to support a -daemon switch or something (so the default was foreground but it's easy to force into the background).
Aaron On Mon, 4 Jul 2005 [EMAIL PROTECTED] wrote: > To get the ball rolling on startup scripts > http://issues.apache.org/jira/browse/GERONIMO-693 , what do people think > about basing the startup scripts (as much as possible) on tomcat's > catalina.bat & catalina.sh > http://cvs.apache.org/viewcvs.cgi/jakarta-tomcat-catalina/catalina/src/bin/ > (since they have been used for years and many users would be familiar with > their style of configuration)? > > Here is my initial list of requirements for startup scripts for > discussion. If anyone else has some requirements to add (please indicate > priority.. e.g. mandatory or nice to have)? I will consolidate comments > into a proposal (e.g. documenting command syntax). > > Server Startup: > ============ > * script must specify -Djava.endorsed.dirs=lib/endorsed to ensure Tomcat > works > * allow plan names to be specified for advanced users. > * start under JPDA debugger if 1st argument is "jpda" instead of "start" > (optional JPDA_TRANSPORT & JPDA_ADDRESS environment variables) > * start under security manager (causes -Djava.security.manager and > -Djava.security.policy==xx to be passed to the JVM) How should a policy > file be specified? > * specify directory for temporary files (e.g. GERONIMO_TMPDIR environment > variable) > * allow jvm options to be passed (e.g. JAVA_OPTS environment variable) > * (for discussion) should the one server startup script also be used for > starting Geronimo as a service? I don't plan to implement this initially, > but would like to plan how we would do it. Currently Tomcat can be > started as a service, but they don't use a script to start it as a > service. See http://jakarta.apache.org/tomcat/tomcat-5.5-doc/setup.html . > Does anyone know if there is a JIRA issue for starting Geronimo as a > service? I can't find one. > > * (for discussion) Can we introduce some type of startup mode parameter > that removes the need for people to remember to start the > org/apache/geronimo/RuntimeDeployer configId). Could having such a > parameter make manuals/books easier to write? I see a few possible modes > of startup (please comment if you can think of others): > - start with previous configuration (no configIds specified as arguments > on Java command). This would be the default mode. > - start with a specific list of configIds. Only these configIds will be > started. > - start with a minimal configuration for J2EE (this includes the > org/apache/geronimo/RuntimeDeployer configuration). > - (future) start with a minimal configuration for non-J2EE use. There > was a discussion on the dev list > - (future) start with a rolled back configuration? > > Server Shutdown > ============== > More thought needed here. Any comments? > > Deploy Tool Startup: > ================= > * starting under JPDA debugger > * allow jvm options to be passed > > Currently the deploy tool accepts some parameters with two leading minus > characters (e.g. --user system). The Tomcat startup scripts currently > have parameters that have a single leading minus character (e.g. > -security). Should the startup script parameters be using the same prefix > (two leading minus characters) as the Java code or should it be using a > different prefix? > > John > > This e-mail message and any attachments may contain confidential, > proprietary or non-public information. This information is intended > solely for the designated recipient(s). If an addressing or transmission > error has misdirected this e-mail, please notify the sender immediately > and destroy this e-mail. Any review, dissemination, use or reliance upon > this information by unintended recipients is prohibited. Any opinions > expressed in this e-mail are those of the author personally.
