Bad classloading, why does Struts continue to use Class.forName()?

[Colin Sampaleanu <co...@exis.com>]

About a year ago we were using the Digester in a non-struts related 
project, and had some pretty bad problems with classloading in an 
environment using 'containers' for various modules, since it used the 
old-style
  Class.forName(xxx)
mechanism to load classes, instead of the recommended
  Thread.currentThread().getContextClassLoader().loadClass(xxx);

I had a bit of discussion about this with Craig, and in the the 
meantime, the Digester in commons got updated to allow it to use the 
context classloader (although not by default).

The problem however, is that Struts, both 1.0.x and lower, and the CVS 
version, continue to use Class.forName() all over the place, and 
continue to use the Digester (either the internal one in 1.0.x with 
Class.forName() or the external commons version with the context flag 
off) in a bad fashion.

In some deployment scenarios, generally when running in an app-server 
like environment, with multiple 'containers', it is extremely 
problematic to use code that does classloading via Class.forName() 
(since the proper versions of classes are not loaded), to the point that 
in many cases the code is not usable. There is generally no argument for 
using Class.forName over the current context classloader, except when 
JDK 1.1 compatibility is required.

We are currently using Struts in a deployment scenario where it is used 
by code in the App Server's main classpath, and it is also used by one 
of the Web Apps running in a container's clasloader lower down in the 
classloader hierarchy. We were not able to get this going until we went 
through the Struts code and changed all the uses of Class.forName to use 
the context classloader isntead, and properly initialized the Digester 
to do so as well. Once this was done there were no problems.

I am willing and able to supply diffs to patch the current CVS version 
in this fashion, but before I do so I would like to knw if they would be 
checked in, or the arguments against it. The alternative approach is to 
make all the code able to work both ways, based on a flag, similar to 
how the commons Digester works right now. The only reason I can see to 
do so is if Struts still needs to run under JDK 1.1 (which I believe it 
can't any longer anyways).

Regards,

Colin



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