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"?
I typed up quite a repsonse to your original message because I'm pretty opinionated about Commons Logging. My guess is that my response didn't make it to the list due to the outstanding network management (couresty of IBM GS) at my client. I'll try to make this brief.
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.
I like the idea of a LogManager far better. It seems like this would protect the configuration better so that the rug won't be yanked out from under the logging framework.
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 not a big fan of Commons Logging. I'm not going into the diatribe I did in my lost message, but suffice it to say that it's one more layer I don't feel we need and I'd rather see it go away. Pick a single logging framework and use it. I vote against the use of Commons Logging.
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.
Please use only Log4J for all Geronimo logging.
Bruce
--
perl -e 'print unpack("u30","<0G)[EMAIL PROTECTED]&5R\"F9E<G)E=\$\!F<FEI+F-O;0\`\`");'
The Castor Project http://www.castor.org/
Apache Geronimo http://geronimo.apache.org/
