geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Dillon <>
Subject Bootstrap logging init...
Date Tue, 27 Feb 2007 02:29:32 GMT
Is there any reason why this is done:

GeronimoLogging.initialize(verboseArg == null || verboseArg.equals 
(ARGUMENT_VERBOSE) ? GeronimoLogging.WARN : GeronimoLogging.DEBUG);
GeronimoLogging.setConsoleLogLevel(verboseArg == null ?  
GeronimoLogging.INFO : verboseArg.equals(ARGUMENT_VERBOSE) ?  
GeronimoLogging.DEBUG : GeronimoLogging.TRACE);

Instead of something like:

GeronimoLogging level = GeronimoLogging.WARN;
if (verboseArg != null) {
     if (verboseArg.equals(ARGUMENT_VERBOSE)) {
         level = GeronimoLogging.DEBUG;
     } else if (verboseArg.equals(ARGUMENT_MORE_VERBOSE)) {
         level = GeronimoLogging.TRACE;

Also, I've noticed that we still end up allowing INFO for console  
output (see the first snippet), which means we end up adding a bunch  
of levels to the server's log4j configuration to limit stuff to above  
INFO, which ends up limiting what goes into the log file, which I  
generally expect to have a bunch more detail.

What do we really want to see on the default console?  I assume this  
output is generally intended for users who don't really care about a  
lot of the internal muck, and really only expect to see ERROR  
(possibly) WARN messages, in addition to the startup monitory and  
shutdown messages.

Assuming this is correct, then we should set the default console  
appenders level to either WARN or ERROR.  I see that in  
GeronimoLogging, the default is ERROR, though I've seen some  
references to where the default should be WARN.

So... why don't we set the default to ERROR (ie.  
GeronimoLogging.initialize(GeronimoLogging.ERROR)) and then set to  
INFO,DEBUG,TRACE with -v, -vv, -vvv?

This should by default make the console output very terse, only  
showing log messages when something bad happens (else its just  
startup/shutdown messages) and then all the wonderful gory details  
can be captured in the log file, w/o needing so many limiting logger  
level entries in the log4j configuration.



View raw message