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.
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.
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 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.
Brian
__________________________________
Do you Yahoo!?
Make Yahoo! your home page
http://www.yahoo.com/r/hs
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
