commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Sitze <rsi...@us.ibm.com>
Subject Re: [logging] Enterprise Common Logging... dare we say 2.0?
Date Sat, 18 Dec 2004 20:18:09 GMT
Developers of open source components that are expected to be plugged into 
different projects simply cannot and should not assume that Log4J, JSR-47, 
Avalon, or any other logger IS present.  This may severely limit the 
logging capabilities that may be used by such components.  This is the 
price we pay to be able to go into a customers shop, install an open 
source solution, and map the logger to their own internal infrastructure 
with minimal code overhead AND minimal impact on their deployment and 
administrative processes.

It's good to know Log4J is growing so strongly, it is an excellent 
project.  I've enjoyed using it myself a few times.


Ceki Gülcü <ceki@qos.ch> wrote on 12/18/2004 11:34:14 AM:

> At 05:44 PM 12/18/2004, Matt Sgarlata wrote:
> >Noel J. Bergman wrote:
> >>
> >>Actually, I agree.  I'd prefer to see that semantic state encoded in 
the log
> >>message, which I feel is much cleaner.
> >>         --- Noel
> >
> >+1.  Just because the JDK 1.4 log does this, doesn't mean that we have 
to 
> >enforce this behavior on all logging implementations.  Why not just 
leave 
> >it generic?  If someone wants enter/exit methods, they can define their 
own:
> >
> >public static void enter(Log log, Class clazz, String method);
> >public static void exit(Log log, Class clazz, String method);
> >
> >Personally, I am against introducing logging that is more specific than 

> >TRACE.  In practice, I think it's hard to explain even the distinction 
> >between TRACE and DEBUG (i.e. - the projects I've seen tend to use one 
or 
> >the other almost exclusively if they're not using INFO or higher for 
the 
> >message).  Again, just because JDK 1.4 offers FINEST, FINER doesn't 
mean 
> >JCL has to.  What happens when the next implementation comes along that 

> >offers 42 different logging levels, including TINY, VERYTINY, 
> >EXTREMLYTINY, TINIEST, SUPPERTINY and SPLITTINGHAIRS logging levels?
> 
> Log4j version 1.4 or 2.0 is likely to introduce the notion of multiple
> domains for categorizing logging statements. When that happens, the
> notion of logging levels will be looked at very differently.
> 
> Commons-logging promises to abstract different logging APIs such as
> log4j, Avalon logkit and java.util.logging API. However, such a task
> is near impossible to fulfill, while Avalon Logkit is nowhere to be
> seen. In the history of software, no one has ever managed to abstract
> competing and divergent APIs without their active cooperation. Chances
> are it won't happen this time around either.
> 
> User who currently use commons-logging are likely to go through a
> lengthy and painful conversion process when they realize that log4j
> offers must-have features.
> 
> 
> >Matt
> 
> -- 
> Ceki Gülcü
> 
>    The complete log4j manual: http://qos.ch/log4j/
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 

*******************************************
Richard A. Sitze
IBM WebSphere WebServices Development


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message