geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <dsundst...@gluecode.com>
Subject Re: Logging problems
Date Mon, 08 Nov 2004 22:34:42 GMT
Yes that is the one.

-dain

On Nov 8, 2004, at 4:03 PM, Aaron Mulder wrote:

> 	If you mean the bit about distribute 1 class or repackage, I vote
> repackage.
>
> Aaron
>
> On Mon, 8 Nov 2004, 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"?
>>
>> -dain
>>
>> 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.
>>>
>>> Commons LogFactory
>>>
>>> Currently all of our code uses commons logging.  The problem is how 
>>> we
>>> obtain org.apache.commons.logging.Log implementation.  This is most
>>> common code in to obtain a Log:
>>>
>>>     private static Log log = LogFactory.getLog(MyGBean.class);
>>>
>>> The problem is the static LogFactory.  As with log4j above anyone can
>>> come along an kick out our log factory.  Also, the code we use to
>>> setup the LogFactory on geronimo boot is very very ugly and error
>>> prone.
>>>
>>> I propose we make "Log log" a GBean magic attributes, which means 
>>> that
>>> is automatically available to all gbeans (just like class loader and
>>> kernel).  If a gbean declares that it wants a log we will create and
>>> initialize a log.  This will also let the kernel add additional
>>> information to log events such as gbean object name.
>>>
>>> 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 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.
>>>
>>> Thanks,
>>>
>>> -dain
>>>
>>> --
>>> Dain Sundstrom
>>> Chief Architect
>>> Gluecode Software
>>> 310.536.8355, ext. 26
>>
>>


Mime
View raw message