+1 on this idea. I would really like to see this stuff in the scripts. Jeff
> -----Original Message----- > From: John Sisson [mailto:[EMAIL PROTECTED] > Sent: Sunday, November 20, 2005 11:24 PM > To: [email protected] > Subject: [LONG] Re: Startup Scripts - foreground and background > > 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/catal > ina/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- > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>> > >>> > >>> > >> > >> > > >
