Bordet, Simone wrote:
I think your concerns are addressed by JSR 277
(http://jcp.org/en/jsr/detail?id=277), scheduled for JDK 7.0 (!).
This is a bit different to me, but inevitably related in some way. Dain
pointed me to the OSGI chapter 4 that defines bundles (JSR 277 also talk
about it). I read briefly the chapter while on the train, but could not
really find something that would define a clear 'firewall system'
between the bundle classloaders and the container. (must read better though)
Tomcat does some kind of filtering (if you put servlet.jar in
WEB-INF/lib) but I think the scope for this filtering is well defined
(or at least restricted).
Yes, this is defined in the servlet specifications (Servlet 2.4
SRV.9.7.2), where it is also 'recommended' to do a current-first rather
than parent-first (java 2 delegation model) for WARs.
Two years ago, I attended a BOF from the SAP guys that work on JMX and
the SAP J2EE application server, and they showed in few slides that
their app server was able to do jar versioning for applications (which
is related to the issues raised). Don't know the details, but it may be
a place to start to look for information.
If anyone has the SAP J2EE app. server, that would be interesting to
figure out how they do. I have been looking in the SAP docs but could
not find some valuable information on the architecture.
The J2EE 1.4 specifications are actually very laxists on these
classloading aspects and have extremely few requirements and some blurry
description of concepts. I do hope that the upcoming J2EE 1.5 specs will
clearly mandate separation between 'internals', 'J2EE apis' and 'common'
(extension ?).
Description of classloaders requirements are described in J2EE.6.2.4.8
and J2EE.8.2 in J2EE 1.4 specs.
I don't know if the TCK actually has any test on this. (and probably
cannot know without signing NDAs :)
JSR 277 also gives few ideas about its scope and implementation, and I
don't see ASF in the expert group members.
This may be of interest as well (jar sealing and package access):
http://java.sun.com/developer/JDCTechTips/2001/tt0130.html
If you remember well when jaxp/crimson first shipped a couple of years
ago with sealed jars, it caused chaos just about everywhere, and afaik
this forced a complete redesign of the classloader architecture of
tomcat for instance (and other servlet engines). It was a good thing
though as it revealed a fundamental flaw.
Long ago a project at CodeHaus, ClassWorlds if I remember well, was
about writing a super classloader with features that would have possibly
allowed versioning and merging.
Don't know the actual status of that project.
Considering the ClassLoader leaks chase Dain has done recently, I would
say it's a delicate issue to play with the current classloader scheme :)
Stephane
