commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Kitching <skitch...@apache.org>
Subject RE: [jcl] mocks
Date Sun, 11 Dec 2005 06:30:56 GMT
On Sat, 2005-12-10 at 21:32 -0500, James Carman wrote:
> I don't know if this has ever been discussed or not, but could we not split
> JCL up into a bunch of different jars containing the different
> implementations?  Each implementation jar (one for Log4J, Avalon, JDK14,
> etc.) would contain a file called something like "/META-INF/jcl-module.xml"
> or whatever.  It could actually just be a properties file, I would imagine.
> Anyway, then that file is looked up at runtime to determine the
> implementation the user wishes to use.  If they want to use log4j, they
> would include the commons-logging-log4j.jar file on the classpath.  If they
> want to use the "no-op" implementation, they'd include the
> commons-logging-noop.jar file on the classpath.  This is similar to what we
> do in HiveMind.  It might work here.  I don't know.  Just a thought.  There
> would be an issue if the user included two different implementations on the
> classpath.  I guess the one that shows up first on the classpath would get
> loaded.   

Something on these lines is likely to be seriously considered for the
release-after-next. 

There have been a number of experiments along this line, though the
focus has been on using build-time stuff to generate classes with the
same classname (LogFactory) which are statically bound to the desired
library. This avoids configuration file issues.

There are still quite a few issues to be thought through for this,
though. It seemed easier to fix the most prominent issues with the
existing JCL design and release that before looking at more serious
rework. Unfortunately all the people working on JCL seem to have run out
of time simultaneously for various reasons. I'm expecting to have some
spare time in January, though, and would love to get a release out
during that month.

Cheers,

Simon



---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message