Exactly, we are bound to either break the axis one, or have axis break
ours. I think the best solution is to simply avoid the static factory
pattern all together.
-dain
On Nov 5, 2004, at 12:00 PM, Davanum Srinivas wrote:
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/
