[Paperclips-discuss] container library classloading

[Nic Ferrier]

The servlet spec states that containers should not expose their
implementation classes to the servlets contained within a webapp.

Personally I think this is a bit mad but I would like to support
it. Gokul did some work on this and I thought he got tied in class
loading knots.

I was thinking about how to solve the problem last night and came up
with the following plan:

Rather than creating a class loader the breaks the delegation mode we
could simply specify a container class library to the command line
client. When the command line client sees the class library specified
it can ensure that it creates a class loader (using the library) to
load the container with.

The user might type something like this:


 java -Dcontainerlib=/paperclips/lib/ gnupaperclips --config=server.xml


The gnupaperclips class can then check the system property
"containerlib" to see if it is defined. If the property is defined it
knows it must do something like this:


  File libDirectory = new File(System,getProperty("containerlib"));
  LibClassLoader cl = new LibClassLoader(systemLoader, libDirectory);


To construct a class loader for the container, that loader can then
be used to load and run the normal boot class (now called
gnu.paperclips.paperclips) like this:


  Class bootClass = cl.loadClass("gnu.paperclips.paperclips");
  Class[] args = new Class[1];
  args[0] = argv.getClass();
  Method mainMethod = bootClass.getMethod("main", args);
  mainMethod.invoke(argv);

Later on, when the webapp class loaders are constructed they can be
buiult by using the System class loader as the delegation target.


That's all fine, and quite fun. There is one small catch however. The
catch is that the gnupaperclips class is part of the paperclips jar
file. I imagine that is how most people will run Paperclips, eg:


  CLASSPATH=paperclips.jar
  java -Dcontainerlib=/paperclips/lib/ gnupaperclips --config=server.xml


This means that the paperclips.jar is on the system class path and
therefore not protected.

The only way round this is for people who want container library
sandboxes to extract the gnupaperclips class from the paperclips.jar
and put it somewhere where they are going to run Paperclips from.

eg:

   jar xvf paperclips.jar -C /usr/local/java/classes gnupaperclips
   CLASSPATH=/usr/local/java/classes
   java -Dcontainerlib=/paperclips/lib gnupaperclips --config ....


I can't think of a nice way of having the makefile build this... I
guess a special install target could do it.

Does anybody have a view?


Nic