+1 to John's proposal
I think it would be nice to have "each configuration together with
its startup time, one configuration per line" noted in the log
geronimo.out file if possible.
-dain
On Nov 21, 2005, at 2:41 AM, David Jencks wrote:
This all seems quite reasonable to me.
I will note that I do not like the current output of the progress
bar startup monitor. I would prefer that it state how many
configurations will be started, and then list each configuration
together with its startup time, one configuration per line. I
think this would work fine both foreground and background.
Thanks,
david jencks
On Nov 20, 2005, at 10:24 PM, John Sisson 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.
Comments?
Thanks,
John
Dave Colasurdo wrote:
Have attached the patches for both unix (.sh) and windows (.bat)
environments to GERONIMO-1166. Please test them out..
Thanks
-Dave-
Dave Colasurdo wrote:
I've opened a JIRA for this issue and created a patch for the
windows platform. Still investigating the unix environment...
http://issues.apache.org/jira/browse/GERONIMO-1166
John Sisson wrote:
Hi Dave,
I don't think I had any objections to making the startup
scripts follow Tomcat as much as possible. See the following
discussions on scripts, I think there were a number of issues
discussed that we need to cover:
http://www.mail-archive.com/[email protected]/msg05926.html
http://www.mail-archive.com/[email protected]/msg05851.html
http://www.mail-archive.com/[email protected]/msg06483.html
Regards,
John
Dave Colasurdo wrote:
Jeff Genender wrote:
Dave Colasurdo wrote:
The shutdown scripts are a step forward in usability over
manually killing the java process via CTL-C. While quite
simple, CTL-C does not seem very user friendly and should
not be the default mechanism.
I really don't believe there is a default mechanism, IMHO. I
think we are offering multiple ways to do the same thing.
The CTRL-C would be heavily used by developers. The shutdown
script could be used by people using a daemon or
backgrounding the server (which is easily done on both
Windows and *nix systems) or a remote server. The console
would/maybe be used by mouse-clicking administrators.
I would surely hope that in a prod environment one is not
running the server in a terminal window ;-)
However, it does seem strange that a user needs to open a
new window to shutdown the server. Seems like the initial
startup command should return the command prompt back to
the user so that shutdown can be issued from the same
window. One way to accomplish this is to have the startup
script launch a new window that controls the java process
(and output the startup messages) while the initial prompt
is returned to the user. This would allow the shutdown to
be issued from the initial window.
For a developer (and me being selfish), running in a terminal
window is not strange and it seems to be the norm from a
command line perspective, rather than the exception.
IMHO, ss a developer, sending the server into the background
is not appealing. I think if one wants control over their
terminal, they could issue a startup.sh& (notice the
ampersand) to background the process. Quite possibly we could
also add another script called startup_background.sh (or bat)
that could so this as well. We could also create daemon
scripts for the different platforms. Wasn't there a JIRA
issue for an NT Service for Windows? We could add init.d
scripts for Unix too.
I agree the current behavior is appropriate for a developer.
I was thinking more about end users. Similar to your
suggestion, should we consider adding an option to the
startup.sh|bat script to put the process in background?
Actually, I'm wondering if the default behavior (startup.sh|
bat w/o any options) should be geared toward end users and
would run the process in background. And specifying the
option (-foreground) would allow the process to be run in the
current window for developers.
Of course, windows service and init.d are also useful. I
think both proposals are worth pursuing
Will look to see if there are current JIRAs open on these..
Also, if we ever support sharing one binary installation
that can start multiple instances of geronimo (each with
it's own unique configuration) then we will also likely need
this behavior.
-Dave-
