Richard: You might find the attached GIF handy ;-)
Gary -----Original Message----- From: Richard Sitze [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 25, 2005 11:41 AM To: Jakarta Commons Developers List Subject: Re: [logging] Enterprise Common Logging... dare we say 2.0? 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > ******************************************* Richard A. Sitze IBM WebSphere WebServices Development
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
