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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
