Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (asf.osuosl.org: domain of dblevins@visi.com designates
 208.42.156.9 as permitted sender)
Date: Tue, 5 Jul 2005 00:16:59 -0700
From: David Blevins <david.blevins@visi.com>
To: dev@geronimo.apache.org
Subject: Re: New Startup Output
Message-ID: <20050705071658.GF18985@django>
References: <Pine.LNX.4.58.0507042152380.2190@saturn.opentools.org>
 <42CA0B83.8070509@savoirtech.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <42CA0B83.8070509@savoirtech.com>
User-Agent: Mutt/1.5.9i

On that note I wouldn't mind a -v -vv -vvv approach for printing log
messages to STDOUT.  Maybe each 'v' could drop the log level down one
notch.

I do like the stuff Aaron whipped up as default.

-David

On Mon, Jul 04, 2005 at 10:24:35PM -0600, Jeff Genender wrote:
> Ok...lets hash this last one out...
> 
> I would really like to have a command line parameter to start Geronimo 
> like "-verbose" that sends the log to the stdout (like it was before). 
> As a developer, its nice to have this instead of having to muck with the 
> log4j files.  Although I could open up another terminal and tail -f the 
> log...this is a real PITA.  Luckily I can do this since I develop on 
> MacOSX.  The windows users may have a more difficult time with this 
> since they lack some of the UNIX commands we are used to (like tail), 
> and would be forced to download cygwin or other.
> 
> For ease of use, a verbose parameter would make good sense, especially 
> for developers.
> 
> I love this new status bar...its really clean...but I would like the 
> option to spew the logs to the terminal.
> 
> I would like to get people's feelings on this since there are 2 sides 
> having this option.
> 
> Jeff
> 
> Aaron Mulder wrote:
> >	I just put in a change with nicer startup console output.  It
> >gives some progress and status information during the server start process
> >and lists the apps deployed and ports used at the end of the startup.  
> >Since it uses \r characters to make it work, the output looks lousy if you
> >view it in a log file, so there's a -noprogress argument you can add to
> >the server command line to suppress it (which the Maven deploy tool does, 
> >for example).
> >
> >	In any case, I'd appreciate any thoughts or feedback on the new 
> >look.
> >
> > * Jeremy's already suggested adding a middle ground between -noprogress
> >   and what's in there, where it would print more or less the same
> >   information but one message per line so it looks nicer in a log.  
> >   There's just an interface to implement to get the startup sequence
> >   calls, so it should be easy enough to support that.
> >
> > * David J recommended the current combination of a short progress bar and
> >   status messages instead of my initial attempt, which just had a long
> >   (but not very fine-grained) progress bar.  I like the way it came out.
> >
> >	Now that I've done this, I think we can use the same technique to
> >hide the password on the deployer command line.
> >
> >Thanks,
> >	Aaron
> >
> >Log message
> >-----------
> >New server startup output
> > - shows a progress bar, timer, and operation status during start
> > - shows a list of started application modules (other than o/a/g/System*)
> > - shows a list of network ports that GBeans tried to bind to
> >The port list is voluntary on behalf of the GBeans.  They must declare an
> >  attribute of type java.net.InetSocketAddress in order to be included
> >  in the list (though it can be a read-only attribute).  We should review
> >  the current GBeans and make sure they do.
> >There is also some logic around calculating the name of a service.  For
> >  example, if the same GBean has more than one InetSocketAddress attribute,
> >  it tries to add the name of each attribute in the port list, and if the
> >  GBean has a "name" attribute (for GBeans tht may be deployed more than
> >  once with different names) it includes that too.
> >The new progress bar does not render particularly well in log files, and
> >  can be disabled by passing -noprogress on the server command line.  The
> >  maven deployment plugin does that.