geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <>
Subject Re: Logging problems
Date Fri, 05 Nov 2004 20:04:14 GMT
Exactly, we are bound to either break the axis one, or have axis break  
ours.  I think the best solution is to simply avoid the static factory  
pattern all together.


On Nov 5, 2004, at 12:00 PM, Davanum Srinivas wrote:

> FYI, In Axis we have our own LogFactory
> ( 
> components/logger/
> -- dims
> On Fri, 5 Nov 2004 11:29:07 -0800, 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
> -- 
> Davanum Srinivas -

View raw message