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]>
