Hi Brian, On Sun, 2005-06-19 at 16:22 -0700, Brian Stansberry wrote: > Had a chance to check this out, and the problem is > because JBoss/Tomcat uses commons-logging.jar instead > of the commons-logging-api.jar used by standalone > Tomcat. When a webapp is deployed JBoss also deploys > container code that executes when the webapps > classloader is the TCCL (e.g. a valve that helps > support the JACC spec). This code fails with > LogConfigurationExceptions due to incompatible Log > interfaces. > > JBoss can't just use commons-logging-api.jar as they > use log4j for server logging.
Yep. Normally, a tomcat adminstrator will also replace the commons-logging-api.jar with the full jar in order to get better control over tomcat's output. > > Good news is, the version of JCL in svn fixes this > problem :) Well, I don't think it should be regarded as such great news (though it's what we deliberately implemented :). What this means is that logging performed by shared classes and jboss framework classes isn't going to the logging destination configured in the webapp, but instead the one configured for the container. So while the app will actually run, there is still a major issue if the user really wants/expects that output in their webapp's standard log destination. The correct fix would be to deploy commons-logging-adapters.jar in the webapp instead of commons-logging.jar; then the conflict between Log classes wouldn't occur and they would get both a working app *and* any output generated by jboss/shared classes when context-classpath is set to the webapp would go to the webapp log destination. Of course because the error is now suppressed, people won't get any hint that the logging output is getting diverted to an unexpected destination - unless they explicitly use a commons-logging.properties file in their webapp to: * point to a specific logging adapter class, or * turn off ALLOW_FLAWED_LOG_HIERARCHY I can live with that though; we can just make it point#1 in the new jcl FAQ that having a commons-logging.properties file specifying an explicit logadapter is a very good idea, and the very first thing to do when anything unexpected is happening. And at least users who don't care about logging aren't brought to a grinding halt. [Brian; I'm sure you knew all this anyway; the info is mostly for other commons-dev watchers and archive-searchers!]. > Well, not quite -- it fixes it once a > patch is applied (see bugzilla 35423). > Man, I'm sure this is going to cause problems some day. This "unified classloader" thing of JBoss feels really really wrong. But I agree completely with your patch; we have to do our best to live with JBoss so toning this down to a warning is what we need to do. Patch committed as r191431. Thanks. > But, they'll probably still keep filtering JCL once a > new version of JCL is out in order to keep apps still > using old versions from blowing up. > Sorry, I understood your comments to say that they aren't really treating JCL specially, it is just a side-effect of their "Unified classloader" stuff (which sounds a really bad idea to me, by the way). Could you clarify these when you get a moment? * are they treating JCL special (refusing loading from webapp)? * if so, which specific classes are they treating special? * which versions of jboss have this "unified classloader" stuff? > BTW, in their nightly builds they've started using a > patched version of JCL whose LogFactory uses a > WeakHashMap instead of a Hashtable. This fixes memory > leak problems in their unit tests. Then that seems good support for bundling WeakHashtable into the main distribution. I'll go ahead and do that, and may as well get rid of the optional jar completely as there's nothing else in there worth keeping. Perhaps it's worth comparing your WeakHashtable with their patch to see if there's anything to be learned there? Actually, maybe we should be discussing whether JCL needs to support JVM1.1 or not. If it doesn't then that weakref stuff becomes a lot easier (and hence more reliable). JCL hasn't supported JVM1.1 for a very long time now (as we found accidentally....) though it probably isn't too hard to restore 1.1 support. In fact, if someone turned up who actually needed JVM1.1 support we could probably fix this fairly quickly. So maybe staying with WeakHashtable is a good idea.. Thanks a heap for testing this with JBoss - it would not have been good to ship something that they can't use. I'll add them to a list of JCL users somewhere on the wiki. Regards, Simon --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
