+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 [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.
