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 21:56:46 GMT
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