On Jun 16, 2005, at 12:04 PM, Bordet, Simone wrote:
Hi,
I think your concerns are addressed by JSR 277
(http://jcp.org/en/jsr/detail?id=277), scheduled for JDK 7.0 (!).
I saw that on the server side yesterday. The problem I see with this
spec is it is already flagged to be part of the JDK, which means that
when a user has a problem they have to wait for sun to fix them.
Also JDK 7? That's ages away.
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).
Yep, Jetty has the same thing.
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.
I'd love to see more details. Anyone out there have a link to how
SAP did this?
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
The problem with using sandbox security is you just get a security
exception. Also, most custom class loader don't implement package
security checks correctly.
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 :)
Yep. One nice thing is it is sooooo core, that when you get it wrong
you normally find out quickly :)
-dain
