geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Mulder <>
Subject Re: Startup Scripts discussion ( GERONIMO-693 )
Date Mon, 04 Jul 2005 15:12:30 GMT
	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).


On Mon, 4 Jul 2005 wrote:
> To get the ball rolling on startup scripts 
> , what do people think 
> about basing the startup scripts (as much as possible) on tomcat's 
> catalina.bat & 
> (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 and 
> 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 . 
> 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.

View raw message