geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <>
Subject Re: Logging problems
Date Tue, 09 Nov 2004 00:00:41 GMT
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?

>>> 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.

>>> 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.


View raw message