WebAppClassLoader / ProxyDirContext.java Problem - Upgrade from T omcat 4.1.12 to 4.1.17

[Matt Small <ms...@Clickability.com>]

A few weeks back I noticed this problem when I upgraded from 4.1.12 to
4.1.17.  I wanted to track it down a little bit before reporting it, and now
I think I know where the problem is. I have isolated the problem to changes
made between CVS versions 1.12 and 1.14 of
org.apache.naming.resources.ProxyDirContext.java. These changes were made
between releases 4.1.12 and 4.1.14 of Tomcat by Remy.

My app dynamically generates java code (in a work dir), compiles it (to
WEB-INF/classes), and then loads it using Class.forName(). This has been
working smoothly and has been very stable for over a year now, way back from
when we were using early versions of tomcat 4 (possibly even in tomcat 3).

The basic algorithm is 

Class c;

public Class getClass() throws Exception{
  try{
    c = Class.forName("generated.ClassName");
  }catch(ClassNotFoundException cnfe1){
    try{
      generateJavaCodeAndCompile(); //compiles to WEB-INF/classes
      c = Class.forName("generated.ClassName");
      return c;
    }catch(ClassNotFoundException cnfe2){
      ERROR class could not be loaded
      throw cnfe2;
    }
  }
}

Note that when a lot of code has to be regenerated, it would take some time,
but it always worked without any trouble. Classes would generate and load in
the order requested by the application.

After upgrading to 4.1.17 I found that when many classes needed to be
generated and loaded, I would get tons of ClassNotFoundExceptions. Even
though my code was being compiled properly and the class was in the webapp
classes dir, the second call to Class.forName was sometimes throwing
ClassNotFoundExceptions.

After trying various combinations of Tomcat jars, I was able to Isolate the
problem to /common/lib/naming-resources.jar. Where the version from 4.1.12
works fine, but 4.1.14 fails. The only file that is different in that
particular jar was ProxyDirContext.java, so I am assuming the problem stems
from those changes.

Anybody have any idea about why this change causes this problem and what a
fix for this would be?

Thanks very much

Matt

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>