commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Sitze <rsi...@us.ibm.com>
Subject Re: [logging] Enterprise Common Logging... dare we say 2.0?
Date Tue, 25 Jan 2005 19:40:35 GMT
Well now... that IS interesting.

<flames on>
How in the WORLD did this happen?  I approached Ceki about aligning JCL 
with Log4J...  and was turned down, he simply wasn't interested and 
wouldn't acknowledge the value of the abstraction [at that time].

This feels like 'not-invented-here' and some backstabbing.  How can we 
POSSIBLY accomplish our goals if we simply refuse to acknowledge that 
other projects have value?!  What can we achieve with competing 
abstractions at this level?

Frankly, I expected better of the Apache Logging Services community.

Excuse me while I go find a wall and beat my head against it for a 
while...
<flames off>

<ras>


news <news@sea.gmane.org> wrote on 01/25/2005 01:21:24 PM:

> I kind of think that.... maybe commons-logging should be deprecated in 
> favor of:
> http://logging.apache.org/log4j/docs/ugli.html
> 
> See UGLI does same thing. But competitions is a good thing; my projects 
> will ship w/ Log4j instead and ugli. One less jar is good.
> .V
> 
> 
> Matt Sgarlata wrote:
> 
> > Richard Sitze wrote:
> >
> >> news <news@sea.gmane.org> 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"?
> >
> > Matt
> 
> 
> 
> -- 
> Forums, Boards, Blogs and News in RiA <http://www.boardVU.com>
> 
> 
> ---------------------------------------------------------------------
> 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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message