commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Kitching <>
Subject Re: [logging] JCL2.0 design - Architecture
Date Mon, 20 Feb 2006 02:28:47 GMT
Hi Remy,

Great to hear from you on this!

On Mon, 2006-02-20 at 01:56 +0100, Remy Maucherat wrote:
> I am not very enthusiastic (from the container perspective). Let's see:
> - Static discovery may look nice to some, but given the most likely
> class overloading rules, it means the whole container and its
> applications would use a single logging framework (which is ok in many
> cases, though). So IMO you need to keep a working dynamic discovery.

Agreed. How I see it working is:

    LogFactory tweaked to delegate to LogFactoryLog4j
    LogFactoryLog4j - concrete subclass log LogFactory
    Log -- standard Log interface
    Log4JLogger -- implementation of Log interface for log4j

    LogFactory tweaked to delegate to LogFactoryJUL
    LogFactoryJUL - concrete subclass log LogFactory
    Log -- standard Log interface
    JULLogger -- implementation of Log interface for java.util.logging

    LogFactory tweaked to delegate to LogFactoryDynamic
    LogFactoryDynamic : essentially the existing LogFactoryImpl

Standalone applications, applets, embedded systems would use a
lib-specific jar eg commons-logging-log4j.jar. No irrelevant TCCL stuff,
no dynamic discovery stuff, only one logging adapter.

Webapps that want to use a specific logging lib would bundle a
lib-specific jar (of course that only works when child-first
classloading is selected or the container doesn't provide JCL). [1]

Containers would generally bundle commons-logging-dynamic.jar, and would
end up with exactly the same functionality that exists now. They *could*
(as you mention) use a lib-specific implementation if they are happy to
have every webapp use one logging lib but commons-logging-dynamic would
be the usual choice.

As a result, this wouldn't reduce any of the existing complexity for
JCL-in-containers (except that we can discard code that tries to handle
embedded systems & java1.1, as those systems can use the lib-specific
ones). However I hope we've nailed many of the outstanding
container-based issues in the 1.1 release anyway, which
LogFactoryDynamic will effectively inherit. This *will* resolve issues
in non-container environments as those can use the simpler jars.

[1] thing we've discovered is that it's a bad idea to have two
jars in the classpath providing the Log interface. JCL1.1 provides a
"commons-logging-adapters.jar" for webapps to use when the container
provides commons-logging.jar. But the proposed jars I've shown here
include Log so aren't safe to use from a webapp when any other jcl jar
is in a shared path. More thought needed :-(

> - Please continue providing support for using the TCCL (as the TCCL -
> or similar - is used in most JNDI impls, doing otherwise is a bit
> redudant as far as I am concerned, and JNDI access is most likely
> slower).

I'd be very interested in your opinion about the safety/stability of
TCCL-based solutions. I was looking at Sun's java bugtracker recently
and found an issue raised by JBoss stating that they wanted some
classloader synchronisation code changed as Marc Fleury has been
experimenting with "dependency-based classloaders that aren't tree
structured". From the comments it seems like a few other people are
experimenting with similar approaches. So is it still going to be safe
in the long run to assume every webapp has a distinct TCCL, and that it
is possible to walk up the classloader ancestry links to find all
possible implementations of a particular class?

> - If you're changing the API, I think you should consider using
> java.util.logging as the facade API to replace the commons-logging 1.0
> API. While the API exposed might be a bit sub optimal, this would be
> the most "standard" way from users' perspective. See JULI in Tomcat,
> and for java.util.logging "implementations" (providers
> may be more accurate), but both are done using the
> full-logging-implementation way, so maybe not very good examples, as
> you would want to only develop facades.

I don't quite understand what you mean here.

Are you suggesting that commons-logging-xxx.jar should include our
implementations of "java.util.logging.*" classes? I don't think that's

Or are you suggesting that we write an implementation of
j.u.l.LogManager so that the commons-logging-xxx.jar can be "plugged in"
as a j.u.l implementation? I had made the assumption that JCL would be
supporting java versions earlier than 1.4. I guess I should check, but I
would think that the consensus is that we can't assume 1.4+ for JCL2.x

Or are you suggesting that we model the JCL api on j.u.l so that moving
between the two is a minor search-and-replace? I agree that j.u.l is
eventually going to be the standard logging interface (5-10 years away)
by virtue of it being in the java standard libs. However there is
significant benefit for the JCL project in keeping changes to the
existing API small; the major users of JCL2.x will be existing JCL1.x
users. In addition, much of the j.u.l API is about configuration which
is something that JCL explicitly doesn't do; it wraps the *logging*
parts only. JCL also has to be a "least common denominator" API, so
deliberately leaves out things like a Level class. By the time all those
things are left out, I don't think the remainder would look much like
j.u.l anyway!

There are a few ideas in j.u.l that we could think about borrowing.
Maybe we could provide "entering" and "exiting" logging calls, which map
to DEBUG level on libs that don't have equivalents? Maybe
fine/finer/finest could be added which map to DEBUG? Personally I've not
seen any great demand for this functionality on the JCL user or dev
lists but if anyone does want these.....

Some of the i18n ideas also need consideration.

> --
> xxxxxxxxxxxxxxxxxxxxxxxxx
> Rémy Maucherat
> Developer & Consultant
> JBoss Group (Europe) SàRL
> xxxxxxxxxxxxxxxxxxxxxxxxx



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message