geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Mulder <ammul...@alumni.princeton.edu>
Subject Re: [LONG] Re: Startup Scripts - foreground and background
Date Mon, 21 Nov 2005 16:14:37 GMT
Regarding -interactive and -noninteractive and David J not liking the output...

I think the better way to do it is to implement a StartupMonitor that
behaves the way you want it to, and then have a single flag to use
that instead of the ProgressBarStartupMonitor (just like now we have a
flag to switch between the silent one and the progress bar).  So there
would not be a "-interactive" flag or a setInteractive method on the
StartupMonitor interface.  There could instead be a "-noninteractive"
flag (though perhaps with a shorter name) that would switch to use a
new StaticStartupMonitor or whatever instead.

Thanks,
    Aaron

On 11/21/05, David Jencks <david_jencks@yahoo.com> 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/dev@geronimo.apache.org/msg05926.html
> >>>>
> >>>> http://www.mail-archive.com/dev@geronimo.apache.org/msg05851.html
> >>>>
> >>>> http://www.mail-archive.com/dev@geronimo.apache.org/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-
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>>
> >>>
> >>>
> >>
> >
>
>

Mime
View raw message