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:[EMAIL PROTECTED]] >Sent: Tuesday, January 15, 2002 1:47 PM >To: [EMAIL PROTECTED] >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:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
