On Tue, 2005-02-08 at 11:30, Ceki Gülcü wrote: > Richard et al., > > Before discussing relatively complex cases you mention, I think it > would benefit everyone to realize that even in the most basic cases > JCL will not work as expected. > > In your examples you refer to commons-logging-api.jar but > commons-logging-api.jar and commons-logging.jar are not > equivalent. The former does *not* include the classes > org.apache.commons.logging.impl.Log4JLogger nor > org.apache.commons.logging.impl.AvalonLogger. Thus, > commons-logging-api.jar cannot bridge to log4j, for the simple reason > that the bridge, Log4JLogger, is not there. > > Consider the following simple set up > > Parent [commons-logging.jar] > ^ > | > Child [log4j.jar] > > Depending on how the thread context class loader is set,and the > delegation model followed by the child loader, the above configuration, in > the best case, will ignore log4j and in many other cases > will throw a LogConfigurationException. > > The following set up will not fair much better (regardless of the > delegation model): > > Parent [commons-logging.jar] > ^ > | > Child [commons-logging.jar, log4j.jar] > > > The only setup that will not blow in your face is the following: > > Parent [commons-logging-api.jar] > ^ > | > Child [commons-logging.jar, log4j.jar] > > Note this is the set up used by Tomcat. Also note that it precludes > the use of log4j by Tomcat itself as commons-logging-api.jar includes > support for java.util.logging but not log4j. If you replace > commons-logging-api.jar with commons-logging.jar, then you must place > log4j.jar next to it unless you enjoy JCL throwing > LogConfigurationExceptions at you. > > The bottom lines is that when compared with any statically bound > bridging mechanism found in UGLI, JCL's dynamic discovery brings no > added value but has a significant cost in aggravation. > > Richard, is there a point discussing complex cases when even the > simplest ones don't work? Were you aware of problems in the above > cases?
(i'm not sure whether i'm missing your point.) it seems to me that it matters not whether the discovery is dynamic or static: the log4j library needs to be available in the classloader. static discovery would break in a similar fashion if a required library is not present. from a practical perspective, i don't really see having to put a number of libraries together so that they are loaded by the same classloader is really a restriction. what matters is that there are ways to achieve the required results and definite instructions are available which are easy for deployers to understand. - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
