commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Kitching <>
Subject Re: [logging] commons logging stubs [was Re: [jci] c#]
Date Thu, 10 Nov 2005 08:04:43 GMT
On Wed, 2005-11-09 at 12:48 +0100, Torsten Curdt wrote:
> > I also talked about removing the commons-logging dependency (which  
> > seemed to be in agreeance at the time),
> > as at least in our environment we don't use it.
> The more I think about this the more I get the opinion we should
> also provide a commons-logging-stub.jar to satisfy commons-logging
> dependencies if you don't like to use it.

Well, ***people can always write their own implementation of the
LogFactory and Log APIs***. Apache isn't going to sue anyone for writing
classes with the package scope org.apache.commons.logging. In fact, this
is definitely the most efficient and reliable way to bind code using the
JCL api to an underlying concrete library.

This is pretty much the approach that the slf4j project uses: a separate
jar for each lib provides different underlying implementations of the
same API. Compile-time tricks are used to generate a family of such 
implementations for well-known logging libraries, but if you're only
writing a bridge to one library then it's easy enough to do by hand.

This approach does have some limitations, I think, but the nice thing
about such a solution is that it's easy enough to transparently provide
a more sophisticated (container-aware, classpath-scanning, all-dancing)
solution: it's just another implementation of the same API as far as
classes using it are concerned.

There's some thought/experiment still to be done over whether compiler
tricks or bytecode engineering is the best way to generate the various
bridges to well-known implementations. And there's the thorny issue of
backwards compatibility.

But to get back to the original issue: if you don't like the way JCL is
implemented, just write your own implementation of two classes with very
simple APIs and use that instead of the JCL standard jar. Problem
solved. The JCL project is as much an API as an implementation.

> Can a new release of CL rule out all the classloading problems
> people had before?

What's currently in SVN head will probably fix 90% of the problems, and
is about 99% backwards compatible. I would love to see it released, so
that the debate could then move on to a "JCL 2.0" which I think is quite
likely to take the alternative approach described above. Oh for a few
more hours in the day!



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

View raw message