FYI, In Axis we have our own LogFactory (http://cvs.apache.org/viewcvs.cgi/ws-axis/java/src/org/apache/axis/components/logger/LogFactory.java).
-- dims On Fri, 5 Nov 2004 11:29:07 -0800, Dain Sundstrom <[EMAIL PROTECTED]> 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 - http://webservices.apache.org/~dims/
