On Sun, 2005-12-11 at 07:53 +0100, Torsten Curdt wrote: > >> Basically all it holds is the Log interface and > >> the LogFactory providing an Log implementation > >> that is doing nothing. > > > > The existing jar already provides NoOpLog.jar. Providing a > > commons-logging.properties file, or setting the appropriate system > > property, ensures that no-op logging is used (the default is SimpleLog > > that just writes to stdout). > > What "NoOpLog.jar"? I know there is a NoOpLog implementation > but that's not the point. Some people just don't want the > dependency.
dependencies should be declared against the API and not the implementation. IMO the biggest mistake made with JCL was that the API jar is not runnable. creating a new NoOp jar and declaring a dependency upon it is positively wrong since that will mess up dependency management graphs. the api jar is now used not only as the basic JCL dependency but also for complex classloader configurations. it's actually a special jar arranged to allow JCL to be deployed in various classloader setups. IMO this was the second fatal mistake in the development of JCL. what's really needed is not a NoOp jar but a jar that's runs containing definitions of the core API (Log and LogFactory) without anything else. (i've taken a look before at creating such a beast and found it difficult.) but that actually satisfy your downstream users? FWIW distributing a combined library with a NoOp implementation may well cause problems with any application using JCL. the possible known classloading configurations would need to be analysed carefully or the presence of NoOp in the classloader hierarchy may well cause problems. IMO it would be more robust to use byte code enhancement to swallow all logging calls (if that's what your downstream customers really want). > And they also don't want to care about a property > file. Instead of everyone providing this mini-jar it would be > nice to have it with JCL IMO. > > Even better I like the idea of having a static selection of the > underlying log system. So having several jars > > commons-logging-[version]-log4j.jar > commons-logging-[version]-noop.jar > ... > > would be a good alternative. Like that. this is ceki's preferred solution. i prefer dynamic binding (run an enhancer against the library in question which does the same job). unfortunately, as far as i can tell, a proper implementation is not possible without breaking backwards compatibility. thanks to hard work by simon and brian, the current JCL is known to be much better than any before. we have a matrix of possible classloader configurations and those which the specifications allow to be solvable appear to work ok now. this does not address the fundamental problems but i think these are better understood now: 1 the J2EE classloader specification is broken, very broken. for political reasons, it's not going to be fixed anytime soon. JCL was coded in the servlet era by folks who are acknowledged experts in the servlet and java 2 specifications. JCL would have worked fine if everyone followed the Java 2 and servlet classloading specifications. unfortunately, since the J2EE specification is broken, JCL cannot work correctly. this cannot be fixed until the specification and every container is fixed. static binding (whether done with different jars or using byte code enhancement) does not have this limitation. 2 the very popularity of JCL is a major problem. with knowledge and correct configuration, the latest JCL will fail to work in a vanishingly small number of real life situations. unfortunately, very few users have the knowledge of classloaders required to fix broken configurations and the popularity of JCL means that the jar has a habit of findings it's way into very difficult classloaders (for example, system classloaders). these are very hostile environments. this problem will not be fixed by a movement to static binding. 3 IMHO the basic usage pattern for JCL suggested in the early days is problematic. private static Log log = LogFactory.getLog() is very widely used and suitable for applications but is difficult for bricks: 3a static utilities should not require logging 3b object libraries should allow themselves to be adapted to the logging system of their host and therefore the log instance should be an instance variable (not a class variable). this poses a difficulty: logging is usually seen as a framework issue and possibly not exposed as part of the public API. Joerg and Jörg have a solution in mind for this but it's on hold until the 1.1 release is cut. BTW i've been having problems with my ISP all week but hopefully i'm back online now. i can make time for JCL but i really need some more eyes on what is a difficult problem. volunteers? - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
