geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruce Snyder <fer...@frii.com>
Subject Re: Logging problems
Date Tue, 09 Nov 2004 04:49:44 GMT
Dain Sundstrom wrote:

> Thanks for the response.  My comments are inline...
> 
> On Nov 8, 2004, at 4:56 PM, Bruce Snyder wrote:
> 
>> Dain Sundstrom wrote:
>>
>>> Either my email got lost in the flood or people are not too 
>>> opinionated on logging.  Anyway, does anyone have an opinion on point 
>>> 2 "Commons Log"?
>>
>>
>> I typed up quite a repsonse to your original message because I'm 
>> pretty opinionated about Commons Logging. My guess is that my response 
>> didn't make it to the list due to the outstanding network management 
>> (couresty of IBM GS) at my client. I'll try to make this brief.
>>
>>> On Nov 5, 2004, at 1:29 PM, Dain Sundstrom wrote:
>>>
>>>> After working with geronimo for a while, I am convinced our current 
>>>> logging solution was a bad idea (on my part :).  There are several 
>>>> problems, so I'll try to categorize them.
>>>>
>>>> Log4j GBeans
>>>>
>>>> Our current log4j gbeans attempt to control the creation of log 
>>>> objects, priories... basically the log4j configuration.  The problem 
>>>> I have found is any application can come along and "reset" the 
>>>> current log4j configuration and reinitialize the system.  I do not 
>>>> believe there is any way to prevent this.  It is on of those 
>>>> problems that everyone had control which in effect gives no one 
>>>> control.
>>>>
>>>> I propose that we drop all of our gbeans that try to control Log4j 
>>>> and instead go to a single gbean that exposes the operations of 
>>>> LogManager, and a log4j.xml file (as a big string).  The big string 
>>>> would be a persisted to somewhere like var/log4.xml.
>>
>>
>> I like the idea of a LogManager far better. It seems like this would 
>> protect the configuration better so that the rug won't be yanked out 
>> from under the logging framework.
> 
> 
> I'm not sure what you mean.  Are you saying you like the idea of 
> exposing LogManager as I proposed, or would you prefer something else?

+1 for the LogManager class.

>>>> Commons Log
>>>>
>>>> If we make the above changes, we will only be using the 
>>>> org.apache.commons.logging.Log class from commons logging.  The 
>>>> problem is to get this class we include a commons-logging jar into 
>>>> geronimo and this jar will carry a specific version number.  This 
>>>> means that all applications are restricted to use the version of 
>>>> commons logging that we ship.
>>>>
>>>> I can think of two solutions this problem: ship only the 
>>>> org.apache.commons.logging.Log class with geronimo or repackage Log 
>>>> into a geronimo package (say org.apache.geronimo.logging.Log or 
>>>> org.apache.geronimo.logging.GLog).  I don't have much of a 
>>>> preference for either of these solutions, but I feel we must address 
>>>> this problem.
>>
>>
>> I'm not a big fan of Commons Logging. I'm not going into the diatribe 
>> I did in my lost message, but suffice it to say that it's one more 
>> layer I don't feel we need and I'd rather see it go away. Pick a 
>> single logging framework and use it. I vote against the use of Commons 
>> Logging.
> 
> 
> I've thought about this, but it would mean that our code is locked to a 
> single log solution.  This means that is someone wanted to swipe our 
> transaction manager they would have to use log4j (for example).  If we 
> instead follow the example of mx4j and use a single simple log interface 
> anyone would be able to adapt it to their logging system.

Build only what we need now, don't get hung up on all the possible 
what-if scenarios. Unless the what-if scenario is a driving factor. I 
haven't seen or been part of any discussions where architecture was 
driven by 'someone [who] wanted to swipe our tx mgr'. (Yes, I'm being a 
smart ass ;-))

>>>> I'm going to start working on the first proposal above, Log4j, as I 
>>>> think it is the least controversial. If you have any concerns about 
>>>> that one, please respond sooner rather then later.
>>
>>
>> Please use only Log4J for all Geronimo logging.
> 
> 
> :)  I wasn't going to go there.  There are many people that think we 
> should use java.util.logging.  I personally think we should shoot for an 
> IOC solution where the integrator of the components (the Kernel in our 
> case) gets to choose the logging system.

Tell me more about the IoC solution. I like the sound of it. But I 
definitely do *not* like the java.util.logging remark.

Bruce
-- 
perl -e 'print 
unpack("u30","<0G)U8V4\@4VYY9&5R\"F9E<G)E=\$\!F<FEI+F-O;0\`\`");'

The Castor Project
http://www.castor.org/

Apache Geronimo
http://geronimo.apache.org/

Mime
View raw message