commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <robertburrelldon...@blueyonder.co.uk>
Subject Re: [logging] requirements and static binding
Date Thu, 19 May 2005 21:15:16 GMT
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message