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 > >
