Fetching latest commit…
Cannot retrieve the latest commit at this time.
|Failed to load latest commit information.|
The code here is an experiment based very heavily upon ideas from SLF4J/UGLI but including the best of JCL too. The code is currently fairly rough around the edges. Comments about fundamental architectural issues are very welcome. Complaints about minor issues like error-checking or spelling are not likely to be received with enthusiasm! The LogFactory and Log classes should be compatible with 99.99% of existing code that uses JCL. Code that *implements* adapters for libraries are simply not compatible - but that's not likely to be a major issue. Run "ant jcl-all" to generate the following jars in target: * commons-logging-core.jar * commons-logging-test.jar * commons-logging-nop.jar * commons-logging-simple.jar * commons-logging-jdk14.jar * commons-logging-log4j12.jar Run "ant test" to execute the (currently very rough) unit tests. Ordinary applications just deploy commons-logging-core.jar AND the appropriate jar for whatever library they want to bind to. In webserver environments: * deploy commons-logging-core *only once*, via a classloader that is not lower than a commons-logging-xxxx adapter jar is deployed. * deploy commons-logging-xxxx adapter jars as often as desired. * if you want code in non-leaf classloaders which use JCL to try to log via loglibs in context classloaders, then set system property "org.apache.commons.logging.context=true". Without this, you get a true "static binding" where code always logs to logging libs in their own classloader. I've got a basic test-harness that demonstrates things, but would prefer to turn it into unit tests before committing it. That should be coming soon.. Benefits: * no auto-detection of logging libs; you deploy commons-logging-xxx.jar, you get logging via xxx. Well, unless you've enabled the "context" feature in which case it might go to whatever commons-logging-yyy.jar is deployed in the context classloader. * very simple * very fast * very small code * JDK1.1 compatible unless you enable the "context" feature. And people shouldn't be running container environments on JDK1.1 anyway! * compatible with almost all existing JCL users Regards, Simon