On Wed, 2006-03-01 at 14:32 +1300, Simon Kitching wrote: > I guess one thing we *could* do is fall back to using LogFactoryImpl if > the system property points to a class that we can't cast to LogFactory. > > That's a pretty scary thing to do though; the application has > *explicitly* set a property to tell JCL which class to use but we ignore > it and use another one instead? What do you think? > > > i'll also try to verify that adding the latest JCL to the appropriate > > system classpath also fixes this problem. > > I don't believe that will fix this situation. > > > > > What we *do* need to consider is whether we can improve the > > > documentation or the error messages to make it clear what the correct > > > fix is. > > > > +1 (see above) > > We could test the class to see if it has an ancestor whose *name* is > "org.apache.commons.logging.LogFactory". If it does, then we have > multiple copies of JCL in the classpath and could emit a warning that > commons-logging-adapters.jar should be used instead. > > That seems like a good idea to me, so unless someone speaks up quickly > I'll add code to do that.
Ok, I've enhanced the diagnostics somewhat. The code is rather complicated and twisty so I wasn't able to add the test I wanted; instead I just give a suggestion about checking for duplicate classes and using the commons-logging-adapters jar file. Cheers, Simon --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
