commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ceki Gülcü <c...@qos.ch>
Subject Re: [logging] Enterprise Common Logging... dare we say 2.0?
Date Sat, 18 Dec 2004 17:34:14 GMT
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


Mime
View raw message