From b744f1e38e91708e6de718d36a5ffbd0ae9ae076 Mon Sep 17 00:00:00 2001 From: Robert Burrell Donkin Date: Sun, 17 Apr 2005 19:31:59 +0000 Subject: [PATCH] Improvements to the tech guide. Contributed by Brian Stansberry. Issue#34412. git-svn-id: https://svn.apache.org/repos/asf/jakarta/commons/proper/logging/trunk@161682 13f79535-47bb-0310-9956-ffa450edef68 --- xdocs/tech.xml | 117 +++++++++++++++++++++++++++++++++++++++---------- 1 file changed, 95 insertions(+), 22 deletions(-) diff --git a/xdocs/tech.xml b/xdocs/tech.xml index 18b5c37..0375edd 100644 --- a/xdocs/tech.xml +++ b/xdocs/tech.xml @@ -118,13 +118,13 @@
  • - - Issues with Context ClassLoaders + + The Context Classloader in Container Applications
  • - - J2EE Context Classloaders + + Issues with Context ClassLoaders
  • @@ -369,9 +369,10 @@ This delegation model therefore naturally forms a tree structure rooted in the bootstrap classloader.

    - Containers often use complex trees to allow isolation of different applications - running within the container. - This is particularly true of J2EE containers + Containers (i.e. applications such as servlet engines or application servers + that manage and provide support services for a number of "contained" applications + that run inside of them) often use complex trees to allow isolation of different applications + running within the container. This is particularly true of J2EE containers.

    @@ -384,6 +385,29 @@ and the second child-first.

    + Parent-first loading has been the standard mechanism in the JDK + class loader, at least since Java 1.2 introduced hierarchical classloaders. + The primary reason for this is safety -- parent-first + makes it impossible for malicious code to trick the JVM into + replacing a core class (say, java.security.SecurityManager) with a + class of the same name loaded from a child classloader. +

    +

    + Child-first classloading has the advantage of helping to improve isolation + between containers and the applications inside them. If an application + uses a library jar that is also used by the container, but the version of + the jar used by the two is different, child-first classloading allows the + contained application to load its version of the jar without affecting the + container. +

    +

    + The ability for a servlet container to offer child-first classloading + 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. +

    +

    Though child-first and parent-first are not the only strategies possible, they are by far the most common. All other strategies are rare. @@ -394,7 +418,7 @@

    - The class loader used to define the class is available programmatically by calling + The class loader used to define a class is available programmatically by calling the getClassLoader method on the class in question. This is often known as the class classloader.

    @@ -403,15 +427,67 @@

    Java 1.2 introduces a mechanism which allows code to access classloaders - which are not parents of the class classloader. - A thread may have a class loader associated to it by it's creator for use - by code running in this thread when loading resources and classes. - This is accessed by the getContextClassLoader method on Thread. - This is therefore often known as the context classloader. + which are not the class classloader or one of its parents. + A thread may have a class loader associated with it by it's creator for use + by code running in the thread when loading resources and classes. + This classloader is accessed by the getContextClassLoader + method on Thread. It is therefore often known as the context classloader.

    Note that the quality and appropriateness of the context classloader depends on the - care with which the thread is created. + care with which the thread's owner manages it. +

    +     + + +

    + The Javadoc for + + Thread.setContextClassLoader emphasizes the setting of the + context classloader as an aspect of thread creation. However, in many + applications the context classloader is not fixed at thread creation but + rather is changed throughout the life of thread as thread execution moves + from one context to another. This usage of the context classloader is + particularly important in container applications. +

    +

    + For example, in a hypothetical servlet container, a pool of threads + is created to handle HTTP requests. When created these threads have their + context classloader set to a classloader that loads container classes. + After the thread is assigned to handle a request, container code parses + the request and then determines which of the deployed web applications + should handle it. Only when the container is about to call code associated + with a particular web application (i.e. is about to cross an "application + boundary") is the context classloader set to the classloader used to load + the web app's classes. When the web application finishes handling the + request and the call returns, the context classloader is set back to the + container classloader. +

    +

    + In a properly managed container, changes in the context classloader are + made when code execution crosses an application boundary. When contained + application A is handling a request, the context classloader + should be the one used to load A's resources. When application + B is handling a request, the context classloader should be + B's. +

    +

    + While a contained application is handling a request, it is not + unusual for it to call system or library code loaded by the container. + For example, a contained application may wish to call a utility function + provided by a shared library. This kind of call is considered to be + within the "application boundary", so the context classloader remains + the contained application's classloader. If the system or library code + needs to load classes or other resources only visible to the contained + application's classloader, it can use the context classloader to access + these resources. +

    +

    + If the context classloader is properly managed, system and library code + that can be accessed by multiple applications can not only use it to load + application-specific resources, but also can use it to detect which + application is making a call and thereby provided services tailored to the + caller.

    @@ -419,20 +495,17 @@

    In practice, context classloaders vary in quality and issues sometimes arise when using them. - The creator of the thread is responsible for setting the classloader. - If the context clasloader is not set then it will default to the system + The owner of the thread is responsible for setting the classloader. + If the context classloader is not set then it will default to the system classloader. Any container doing so will cause difficulties for any code using the context classloader.

    - The creator is also at liberty to set the classloader as they wish. - Containers may set the context classloader so that it is nether a child nor a parent + The owner is also at liberty to set the classloader as they wish. + Containers may set the context classloader so that it is neither a child nor a parent of the classloader that defines the class using that loader. Again, this will cause difficulties.

    - - -

    Introduced in Java J2EE 1.3 is a requirement for vendors to appropriately set the context classloader. @@ -469,7 +542,7 @@ above.

    - Reflection cannot bypass restrictions imposed by the java langauge security model but by avoiding symbolic + Reflection cannot bypass restrictions imposed by the java language security model, but, by avoiding symbolic references, reflection can be used to load classes which could not otherwise be loaded. Another ClassLoader can be used to load a class and then reflection used to create an instance.