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! Regards, Simon --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
