--- Brian Stansberry <[EMAIL PROTECTED]> wrote: > --- robert burrell donkin > <[EMAIL PROTECTED]> wrote: > > On Thu, 2005-05-05 at 23:12 +1200, Simon Kitching > > wrote: > > > On Wed, 2005-05-04 at 23:37 -0700, Brian > > Stansberry wrote: > > > > <snip> > > > > > > 2) When checking into the above, I discovered > > that in > > > > the latest JBoss, their webapp classloader > won't > > load > > > > commons-logging.jar from WEB-INF/lib even if > > > > parent-last loading is in effect. It's > > specifically > > > > disabled. Seems there were type conflicts > with > > JCL > > > > classes loaded by the integrated Tomcat > > container. > > > > Not sure yet what this is all about, but in > any > > case > > > > the net effect is that as far as JCL is > > concerned, a > > > > webapp on JBoss behaves as if parent-first > > loading > > > > were in effect. > > > > > > Interesting....I wonder if they posted any > > questions to the JCL > > > development list before adopting this > (apparently > > fairly radical) > > > solution. I'll go have a look. > > > > seems like an odd solution. any more information > on > > this? > > Not too much. The JBoss CVS commit history and > their > JIRA don't give too many details. For JBoss 4.0.2 > they switched to using the standard Tomcat webapp > classloader by default (instead of their own). I'm > *guessing* that the problem might arise because > JBoss > has commons-logging.jar on the server classpath, > while > Tomcat standalone use commons-logging-api.jar. > > I'm about to take on a project related to > JBoss/Tomcat > integration, so that will give me a chance to check > it > out more (i.e. stop filtering JCL in WEB-INF/lib and > see what breaks).
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. Good news is, the version of JCL in svn fixes this problem :) Well, not quite -- it fixes it once a patch is applied (see bugzilla 35423). 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. 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. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
