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, 25 Jan 2005 15:57:49 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
> 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].

I think we can pretty much lay to rest the argument that including 
ENTER/EXIT is a "best practice".  There have been so many arguments on 
both sides of the issue that it's pretty clear we're not going to reach 
a concensus.  A best practice is something like database connection 
pooling, which everyone agrees is a good idea.  ENTER/EXIT is a highly 
contentious issue, given that this debate has been raging for weeks.

I still don't understand why if you want enter/exit methods you can't 
just do it in your own static method somewhere like shown below.

MyLoggingUtils.enter(MyClass.class, "myMethodName", new Object[] { arg1, 
arg2, arg3 }).

Does JDK 1.4 logging do something really fancy with ENTER/EXIT methods 
that makes you argue so strongly for them?  Or is there something in 
that IBM alphaworks project that depends on the enter/exit methods? 
Couldn't it be rewritten to filter TRACE level logging that began with 
the text "Entering" or "Exiting"?


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

View raw message