geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Mulder <ammul...@alumni.princeton.edu>
Subject Re: Logging problems
Date Mon, 08 Nov 2004 22:03:47 GMT
	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