geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <d...@iq80.com>
Subject Re: New Startup Output
Date Tue, 05 Jul 2005 15:15:00 GMT
Aaron,

You can get the server version from the ServerInfo class.  Also we  
already control initializing the default log level in the main  
class.  I believe we can  implement -v -vv -vvv options by setting  
the initial default log level to error, info or debug.  If that  
doesn't work, I believe that system properties are available to log4j  
properties files, so we could have a geronimo.log.level.default which  
we make available to be consumed by which ever log implementation we  
choose.

-dain

On Jul 5, 2005, at 4:24 AM, Jeff Genender wrote:

>
>
> David Blevins wrote:
>
>> 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.
>>
>
> Absolutely.  I think Aaron's status bar is great as a default.  But  
> we really need an easy way to get the logs to stdout in a quick and  
> easy manner.
>
>
>> -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.
>


Mime
View raw message