Skip to end of metadata
Comment: Migrated to Confluence 4.0
Go to start of metadata

Introduction

The ClassMan toolkit integrated into Loom is a set of utility classes that enable ClassLoader hierarchies to be constructed from xml configurations. The toolkit supports hierarchial ClassLoaders and ClassLoaders defined by directed graphs via the use of "Join" ClassLoaders that can have multiple parents. This results in construction of a ClassLoader lattice.

Each non-Join ClassLoader can be defined in terms of;

  • Entrys: URLs designating either a directory or a file
  • FileSets: Sets of files defined in a manner similar to Ants Filests.
  • Extensions: Definitions of Extensions, aka "Optional Packages".

Each ClassLoader also has a name and a parent. The parent is the name of the parent ClassLoader. Usually the parent ClassLoaders are one of the predefined ClassLoaders. The predefined are passed into the ClassMan toolkit from external application code.

The predefined ClassLoaders are generally named according to a pattern that places the '' at start and end of name. ie "*myPredefinedClassLoader". Loom predefines the following classloaders.

  • system: The System ClassLoader.
  • common: Common between container and application code.
  • shared: Shared between all application code. Note: This is currently equivelent to common.

The commented DTD describes the descriptor format explicitly.

Loom Sample

Let us also assume that we want to host a servlet container (like Catalina, Jo! or Jetty) in Loom. The servlet specification requires that the servlets are capable of "seeing" the servlet API but recomends strongly that no servlet should be able to access any container specific classes.

To satisfy this requirement we decided to place the Servlet API classes in a parent ClassLoader to the Containers ClassLoader and each Web Applications ClassLoader. ie

     Servlet API CL
           |
    +------+------+
    |             |
 Servlet        WebApp
Container         CL
    CL

This way, both the Container and the WebApp ClassLoaders will load the Servlet API from the same ClassLoader.

Unfortunately, in our case Loom already assembles the Servlet Container CL by default and does not give us the opportunity to construct the Servlet API CL as a parent ClassLoader. Luckily we can overide this using the ClassMan toolkit using the following configuration file.

The first thing you notice about this is that the ClassLoader hierarchy is much more complicated. In fact the diagram now looks like;

          "servlet-api"   "jndi-api"
               CL             CL
                |             |
                +------+------+
                       |
 "*common*"    "webapp-common" CL
       |               |
       +----+   +------+------+
            |   |             |
         "container-        WebApp
             base"            CL
               CL         (This is constructed
               |           by Container but
          "container"      shown for completeness)
                CL

In reality we could have merged "servlet-api" and "jndi-api" into "webapp-common" but we separated them for illustration purposes.

The above demonstrates one of the most complex examples that you are likely to come across. This arose because there was multiple "containers" hosted in same ClassLoader hierarchy. The Servlet API specification requires that implementation classes not be visible to API clients. The Loom API specification requires the same thing.

Labels
  • None