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? > > > > 3) Thinking again of the DefaultServlet and JSPServlet > > in Tomcat. These classes are loaded by a container > > classloader, but the logging of a specific instance of > > the classes should be governed by the configuration of > > the webapp. AFAICT, this will require dynamic > > discovery based on the TCCL. > > I'm not sure that logging from such classes *should* use the logging > configuration of the webapp. I discussed this in my earlier email: > <simon> > > What about when a webapp calls a method on an object passed to it by the > > container, and that method logs stuff? Well, in that case there's no > > guarantee that the called object uses JCL anyway, so catching logging > > from such objects really relies upon the container providing > > container-specific hooks to redirect logging. And in that case logging > > calls will end up in webapp-specific code that will statically bind via > > the webapp classloader. So no problem. > </simon> > > I too prefer the simplicity (and lack of memory leaks) > > of static binding, but given the above and the recent > > discussion continue to see a long life for dynamic > > discovery as well. This gets me thinking of how > > carefully we're going to have to document things when > > we provide both static and dynamic discovery. For > > example, if we provide a commons-logging-jdk14.jar, > > we'll have to make clear that deploying it with your > > EJBs won't work if the container has > > commons-logging.log4j.jar on the classpath, that it > > won't work in a webapp on JBoss, etc. > > Ecch.... > > > This is great info, Brian. I'll need to mull it over a bit more. good work brian +1 - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
