geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruce Snyder <bruce.sny...@gmail.com>
Subject Re: [LONG] Re: Startup Scripts - foreground and background
Date Mon, 21 Nov 2005 13:14:01 GMT
On 11/20/05, John Sisson <jrsisson@gmail.com> wrote:
> I am reviewing Dave's startup patches ( GERONIMO-1166 ) and have a
> couple of ideas for comment.
>
> [1]. I propose we provide a geronimo.sh file that is modelled on
> Tomcat's catalina.sh file (
> http://svn.apache.org/repos/asf/tomcat/container/tc5.5.x/catalina/src/bin/
> ), as a large number of users would already be familiar with its syntax
> and environment variable naming conventions and it would be good if we
> had some consistency across Apache products.
>
> geronimo.sh would support options such as:
>
> jpda start    - Start Geronimo under JPDA debugger
> run             - Start Geronimo in the current window (same as Dave's
> proposed -foreground)
> start           - Start Geronimo in a separate window (same as Dave's
> proposed -background)
>
> Also make startup.sh consistent with Tomcat's startup.sh and move the
> redirection logic and foreground/background logic to geronimo.sh.
>
> If we are consistent with Tomcat it means that if an option isn't passed
> to geronimo.sh (e.g. start) then usage information will be printed to
> the terminal. If users invoke startup.sh, it in turn invokes geronimo.sh
> with the start option (consistent with Tomcat).
>
> I am happy to make these changes if I have no objections.
>
> [2]. File name used for redirected output when using startup.sh -background
>
>     Currently the patch redirects output to a startupProgress.log file.
> I am thinking the file should be renamed to geronimo.out (consistent
> with Tomcat's catalina.out) since it may contain more than startup
> messages over the life of the process.
>
> [3]. Improving format of progress messages in redirected output when
> using startup.sh -background
>
> For the startup output to not appear garbled in the file that output is
> redirected to (due to the carriage returns generated by
> ProgressBarStartupMonitor) we probably need a modified version of
> ProgressBarStartupMonitor that outputs a line when a configuration is
> starting/started (without the update thread that updates the line approx
> every 500ms that the ProgressBarStartupMonitor has).
>
> I initially thought we could use the -quiet option, but that results in
> no progress being output and it would be nice to be able to look at the
> geronimo.out file to see what is happening rather than having to look
> through possibly heaps of messages in the log4j log files.
>
> It would be also be helpful if the output redirected to the geronimo.out
> file also has the summary of listening ports and started application
> modules & web applications.
>
> [4]. Proposed new Geronimo startup options:
>
> -interactive (default)
>         Specify this when output is sent to an interactive
> terminal/console.  During startup (if -quiet is not specified) the
> progress message for a configuration will be updated approx every 500ms
> (using carriage returns to move the cursor on the display to the
> beginning of the current line to enable the progress message to be
> updated.  Mutually exclusive with the -noninteractive parameter.
>
> -noninteractive
>         Specify this when output is being redirected to a file or
> printer.  During startup, a new message (each message on a new line)
> will be issued during different stages startup. Mutually exclusive with
> the -interactive parameter.
>
> The above option could also be stored in case in the future we want to
> enhance shutdown processing to show some progress messages.
>
> The startup.sh script would pass -noninteractive if the process is
> started in the background.
>
> [5]. New method on StartupMonitor interface
>
> A new method setInteractive(boolean b) could be added to the
> StartupMonitor interface and invoked by the Daemon class before the
> systemStarted(kernel) method is called.

These are all very good ideas, John. I really like the idea to model
our scripts after Tomcat's scripts. Surfing off of users potential
familiarity with the Tomcat scripts is an awesome idea. This should
help to break down some barriers for users immediately.

Bruce
--
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'

The Castor Project
http://www.castor.org/

Apache Geronimo
http://geronimo.apache.org/

Mime
View raw message