commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Sgarlata <>
Subject Re: [logging] Enterprise Common Logging... dare we say 2.0?
Date Tue, 21 Dec 2004 20:01:07 GMT
Richard Sitze wrote:
> news <> wrote on 12/21/2004 08:04:09 AM:
>>+1, I agree with you and Ceki.  TRACE is debatable (I personally like 
>>it), more than TRACE is silly.
> Well... call them what you will, I want em'!! lol

Does this mean you want all 42 logging levels I described in my previous 
and SPLITTINGHAIRS logging levels I mentioned in a previous post?

Just kidding!  That was a joke, please don't flame me because of it :)

> And yes, I'm leaning towards EXPLICITLY naming methods to encourage best 
> practices.  To use the distinction made by Curt, I'm pushing the trace 
> level methods towards diagnostic logger function, and stepping away from 
> other uses entirely.  I'm going to refrain from doing a full brain dump on 
> all the fun thoughts now running through my head... [separating trace 
> level methods and messaging/admin level methods into seperate interfaces.. 
> ok I lied].

OK, I'm being serious again.  I think there are two problems with "best 
practices": (1) they change and (2) they are in the eye of the beholder. 
   Nothing can be deemed "best" without making a value judgement, which 
means that reasonable people can disagreee as to what is the "best" 

Bringing this back to the situation at hand, you think enter/exit are 
best practices, I think they're as useful as the SUPERTINY log level. 
But let's not take my word for it.  Consider that Log4J doesn't include 
enter/exit and it is the pioneer logging framework that's still going 
strong despite an attempt to hijack its charter by including logging in 
the Java language itself.  This leads me to believe your argument that 
enter/exit is a best practice is debatable at best :)

> 3 levels stand out clearly to me:
> component level tracing [flow] - particularly useful in a larger system
> class level tracing [flow]
> additional detail

I still don't understand this distinction, but I am comfortable taking 
your word for it that this is very important.  It would probably be a 
great feature for Log4J instead of JCL :)

>>>richard's proposal to add symantic methods (rather than severities) is 
>>>therefore interesting. exit and entry tracing is common. at the 
> moment, 
>>>this works rather poorly when JCP is used with log4j: most people log 
>>>these at trace which is mapped to debug by the bridge. unfortunately, 
>>>this has the effect of making debug level almost unusable. separate, 
>>>symantically meaningful methods would have the advantage that the 
> bridge 
>>>will know enough to make better choices.
>>-0.  This is moving JCL out of the realm of bridging logging APIs and 
>>into the realm of providing logging implementations.  For Log4J, 
>>enter/exit methods will end up being mapped to Log4J's DEBUG level. 
>>This means that JCL will have to provide the implementation that 
>>converts the enter/exit calls into DEBUG calls with a specific format.
> This is what the thin wrapper DOES.  Not sure I understand your issue.
>>What format should be used?  Are we going to force one on users of Log4J
> We should adopt a helper method to do such formatting, and use it [common] 
> across all components to standardize this as much as possible.  Where 
> logger impls support such, we pass as much as makes sense straight 
> through.
> Let's not get hung up on formatting issues, the POINT is to capture 
> information, enable the developers, etc.
>>or make it configurable?  And if it's configurable, that stinks of JCL 
>>becoming a logging *implementation* rather than *bridge*.  Yuck!  If I 
>>was a committer (you're probably glad I'm not!) I would probably -1 the 
>>enter/exit methods.
> No problem, I'd just keep beating at your arguments until my last dying 
> breath. ;-)

Hehe that worked on me last time :)  I think it won't this time though!

>>>(so, i'm a little unsure about this issue at the moment.)
>>>- robert
> *******************************************
> Richard A. Sitze
> IBM WebSphere WebServices Development

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message