You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by Ceki Gülcü <ce...@qos.ch> on 2004/12/18 18:34:14 UTC
Re: [logging] Enterprise Common Logging... dare we say 2.0?
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: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [logging] Enterprise Common Logging... dare we say 2.0?
Posted by Richard Sitze <rs...@us.ibm.com>.
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ü <ce...@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