On Sun, 20 Mar 2005 08:29:56 +0000, robert burrell donkin
<[EMAIL PROTECTED]> wrote:
> On Sun, 2005-03-20 at 13:49 +1200, Simon Kitching wrote:
> > On Sat, 2005-03-19 at 23:12 +0000, robert burrell donkin wrote:
> > [snip]
> > By the way, despite reading a significant amount of documentation and
> > code for various containers and posting to a number of email lists, I
> > have found absolutely ZERO information on *why* some containers provide
> > a parent-first option at all. Even tomcat does so (<loader
> > delegate="true"/>) but doesn't document why this feature is provided,
> > and Remy Maucherat (who appears to be the author) hasn't responded to my
> > email.
>
> FWIW i seem to recall that parent first classloading models emerged in
> the early days of ejb's from the enterprise (rather than the servlet)
> side. maybe support for parent first loading models could have been an
> implicit specification requirement (part of the TCK, say).
Parent-first loading has been the *standard* mechanism in the JDK
class loaer, at least since Java2 (JDK 1.2) introuced separate class
loaders. The primary reasoning around this is safety -- parent first
makes it impossible for a client class loader to trick the JVM into
replacing a core class (say, java.security.SecurityManager) with a
class of the same name loaded from a malicious client class loader.
The ability for a servlet container to offer a different model is made
available, as an option, by language in the servlet spec (Section
9.7.2) that allows a container to offer child-first loading with
certain restrictions, such as not allowing replacement of java.* or
javax.* classes, or the container's implementation classes -- for
Tomcat, for example, that would be things in $CATALINA_HOME/server.
> [snip]
> i also think that we really need to be recommending that deployers think
> about undeployment. log systems have difficulties during hot deployment.
> if you aim to hot-deploy a self-contained web application then this
> should contain appropriate life cycle listeners so ensure that the log
> system has time to close down correctly. this is also the right time to
> call release if you use JCL.
Application frameworks can assist in this endeavor by including their
own shutdown logic for the libraries that the framework itself depends
on. For example, last night I added the following to the shutdown
logic for Shale:
CatalogFactory.clear();
PropertyUtils.clearDescriptions();
LogFactory.release(Thread.currentThread().getContextClassLoader());
and the same thing needs to be added into Struts 1.x.
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
