getContextClassLoader() is a way for someone up the heirarchy to let someone down the heirarchy know which class loader to use.
For example, if I have a Servlet container and my Serlvet is running in a special class loader X (for implementing reloading), and the Servlet calls some external library (in the App or Ext class loaders), and that external library has to load and initialize one of the classes in the Servlet JAR, the only way to make that magic work is using the context class loader. I have no clue, though, why it would be needed in SAXParserFactory. Typically javax.xml.parsers would be running in the system class loaded, and the parser should be running either there or in the application class loader. I don't know of any application where I would want to create a parser from my Serlvet where the parser code is coming from the Servlet class loader. Especially if it breaks 1.1 compatibility. arkin Pierpaolo Fumagalli wrote: > > Wong Kok Wai wrote: > > > > I like to ask a question on the implementation of > > javax.xml.parsers.SAXParserFactory: Why is the advantage of using > > Thread.currentThread().getContextClassLoader().loadClass() to load class > > compare to Class.forName()? > > > > (This implementation also mean Xerces cannot be compile with JDK 1.1.x). > > There's a HUGE document somewhere @ Sun explaining why and how > Class.forName() shouldn't be used in JDK 1.2 environments, and that's > the recomandation they give... > > I don't know, do I have to change it? Votes? > > Pier > -- > -------------------------------------------------------------------- > - P I E R - > stable structure erected over water to allow the docking of seacraft > <mailto:[EMAIL PROTECTED]> <http://www.betaversion.org/~pier/> > -------------------------------------------------------------------- > - ApacheCON Y2K: Come to the official Apache developers conference - > -------------------- <http://www.apachecon.com> --------------------