geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephane Bailliez <>
Subject Re: ClassLoader Architecture
Date Thu, 16 Jun 2005 23:58:07 GMT
Bordet, Simone wrote:

> I think your concerns are addressed by JSR 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. 
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):

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


View raw message