One other thought. Perhaps a utility method should be added (where?) that the various Struts classes would use when needing either a new Class instance or a new instance for a given Class.
Donnie > -----Original Message----- > From: Donnie Hale [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, January 15, 2002 10:06 PM > To: Struts Developers List > Subject: RE: Bad classloading, why does Struts continue to use > Class.forName()? > > > Craig, > > I thought the context classloader was defined to be the same as the loader > you'd get via "class.forName" if the context classloader had not otherwise > been explicitly set. From the javadocs for getContextClassLoader: > > ======================== > Returns the context ClassLoader for this Thread. The context > ClassLoader is > provided by the creator of the thread for use by code running in > this thread > when loading classes and resources. If not set, the default is the > ClassLoader context of the parent Thread. The context ClassLoader of the > primordial thread is typically set to the class loader used to load the > application. > ======================== > > Maybe I'm reading too much into that. What I'm surmising is that > servlet 2.2 > environments which don't properly use a classloader delegation chain will > still implicitly have a usable context classloader. Am I missing > something? > > Donnie > > > > -----Original Message----- > > From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] > > Sent: Tuesday, January 15, 2002 3:25 PM > > To: Struts Developers List > > Subject: Re: Bad classloading, why does Struts continue to use > > Class.forName()? > > > > > > The patches to deal with this are straightforward. My concern > is that the > > context class loader is ***not*** guaranteed to be accurately set in > > servlet 2.2 environments (although it is now required to be in > the webapp > > class loader in servlet 2.3). > > > > Does anyone know of a current platform that Struts runs on that does not > > set the context class loader in their current versions? (If there are > > none, we can probably go ahead and change the default, at least in the > > 1.1 branch). > > > > Craig > > > > > > On Tue, 15 Jan 2002, Colin Sampaleanu wrote: > > > > > Date: Tue, 15 Jan 2002 13:46:53 -0500 > > > From: Colin Sampaleanu <[EMAIL PROTECTED]> > > > Reply-To: Struts Developers List <[EMAIL PROTECTED]> > > > 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]> > > > > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
