commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Sitze <>
Subject Re: [logging] Enterprise Common Logging... dare we say 2.0?
Date Tue, 21 Dec 2004 22:07:28 GMT
news <> wrote on 12/21/2004 02:01:07 PM:


> > And yes, I'm leaning towards EXPLICITLY naming methods to encourage 
> > practices.  To use the distinction made by Curt, I'm pushing the trace 

> > level methods towards diagnostic logger function, and stepping away 
> > 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 
> > 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" 
> practice.

Agreed.  Looking for balance, there are some things that are more clear 
than others.

> 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 

I want to turn on logging that tracks component boundries.  When I enter 
my component [or robert's brick], and when I leave it.  Perhaps log data 
exchanged across the boundry.

> > class level tracing [flow]

Ok, now that I'm IN my component, I want to track the flow between objects 
/ methods.  Again, data exchanged on method invocation / return.  This 
corresponds to the proposed enter/exit.

I'm agreeing with comments by others, in that [generally] I don't want to 
log just any old thing here, but I for loggers that do support multiple 
log levels, would be useful to have this without the next level down..

> > additional detail

Capture details on internal data, track low level flow if desired... 
everything else.

> 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) 
> > 
> > 
> >>>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 
> > 
> > 
> > We should adopt a helper method to do such formatting, and use it 
> > 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 
> >>enter/exit methods.
> > 
> > 
> > No problem, I'd just keep beating at your arguments until my last 
> > breath. ;-)
> Hehe that worked on me last time :)  I think it won't this time though!

I'm not done yet :)

Richard A. Sitze
IBM WebSphere WebServices Development

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

View raw message