geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Genender <>
Subject Re: Startup Scripts discussion ( GERONIMO-693 )
Date Mon, 04 Jul 2005 15:45:45 GMT
+1 on the switch idea.  It would be nice to have this sort of control.

Aaron Mulder wrote:
> 	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 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 
>>* 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 
>>* 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 
>>  - 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?
>>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