struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Colin Sampaleanu <colin...@exis.com>
Subject Re: Bad classloading, why does Struts continue to use Class.forName()?
Date Tue, 15 Jan 2002 20:35:25 GMT
Thanks. The bug report mentions the Digester only, but the problem is 
not only with the usage of the Digester though, it is with Struts 
itself. We have a legitimate use for Struts at several levels, and the 
current use of Class.forName() for classloading in a number of places 
breaks things.

Deadman, Hal wrote:

>I filed a bug report for this same problem.
>
>http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5774
>
>-----Original Message-----
>From: Colin Sampaleanu [mailto:colinml1@exis.com]
>Sent: Tuesday, January 15, 2002 1:47 PM
>To: struts-dev@jakarta.apache.org
>Subject: Bad classloading, why does Struts continue to use
>Class.forName()?
>
>
>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:   <mailto:struts-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-dev-help@jakarta.apache.org>


Mime
View raw message