commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Kitching <skitch...@apache.org>
Subject Re: [logging] requirements and static binding
Date Thu, 05 May 2005 11:12:33 GMT
On Wed, 2005-05-04 at 23:37 -0700, Brian Stansberry wrote:
> A few semi-random points on parent-first vs.
> parent-last classloading:
> 
> 1) EJBs, EARs and other non-webapp J2EE deployments
> typically use parent-first loading.  I'd thought JBoss
> offered a deployment descriptor option that allowed
> the deployer to choose parent-last, but I was
> mistaken.  Too bad; I was hoping the scope of the "if
> you want control, use parent-last classloading"
> approach would apply.

Well, if the EJB spec is designed to prevent EJBs from overriding jars
present in the parent classloader, who are we to argue?

In other words, if a JCL logging implementation is in the parent
classloader, then why not just bind to it? 

This doesn't give the EJB developer any control over what logging lib is
used (though they don't typically need such control). 

More controversially, it doesn't give any control to the "application
assembler", as any jar they bundle will be ignored if the container
provides an implementation. But that's the way the J2EE spec wants
things to work it appears.

And potentially even more controversially, it doesn't give any control
to the "application deployer" unless they are also a system
administrator for the container (and are willing to change the logging
lib globally). But again, if the J2EE spec authors chose "parent first"
as the only option, then that must be what they wanted to happen.

Or is it just JBoss that has adopted this position for EJB deployment I
wonder?

> 
> 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.

> 
> 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. I admin
I've been playing "devil's advocate" a bit above; may need to reconsider
in the face of reality :-)

Thanks,

Simon



---------------------------------------------------------------------
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