But the org.apache classes are not endorsed, only the org.xml.sax and org.w3c.dom. These packages contain mostly interfaces and while the implemenation of the JDK comes with the org.apache classes I do not believe these are considered part of the J2SE platform API.
JAXP comes with a specific override mechanism such that if a JAXP implementation is found on the classpath that one can be used ahead of any other implementation. Otherwise developers would be stuck with the JAXP parser in the JRE. This means that a parser in mywebapp/web-inf/lib should be used ahead of any other provided you are using SAXParserFactory/DocumentBuilderFactory to load the parser. At least this is my reading of the JAXP specification and certainly the behaviour I've seen running XML apps from the command line and making sure that I have Xerces/Xalan on the classpath for the application. BTW I'm butting in here assuming I know the whole thread, and this is also a subject dear to my heart as I've had so many go arounds of this on so many different Tomcat versions. BTW2 the Servlet specification was written with exactly this problem in mind, i.e. making sure the 'right' XML parser was loaded Kevin Jones On Fri, 2003-10-10 at 18:16, Cox, Charlie wrote: > ok, I just found this link from the archives. Sun defined that you have to > use the 'endorsed' directory or take the Sun-supplied versions of the > packages listed. > http://java.sun.com/j2se/1.4.2/docs/guide/standards/index.html > > tomcat's classloading is enforcing this requirement explicitly since it does > not delegate to the parent classloader first. > > so you can only replace the version in /endorsed > Charlie > > > -----Original Message----- > > From: Lee, William [mailto:[EMAIL PROTECTED] > > Sent: Friday, October 10, 2003 12:05 PM > > To: 'Tomcat Developers List' > > Subject: RE: Webapp classloader question. > > > > > > It seems to me that we are going for "bandaid" solution here. > > By moving > > around the files, it will work for one particular webapp, but at the > > expensive of the compatibility of other webapp under the same > > tomcat. As > > soon as we move the parser out of one webapp, we are forcing all other > > webapp using the same parser, which I believed is not the > > right way to go. > > > > Rather, why forcing the delegate model for these two > > particular packages > > (xerces & xalan)? Isn't it true that the endorse mechanism > > only required > > that the endorsed directory should be traverse before the system? > > > > I still didn't see the reason how this "endorsed mechanism" > > has anything to > > do with the servlet spec., and that it would force servlet > > container to skip > > the one in webapps? > > > > Thanks again. > > William. > > > > > > -----Original Message----- > > From: Cox, Charlie [mailto:[EMAIL PROTECTED] > > Sent: Friday, October 10, 2003 8:46 AM > > To: 'Tomcat Developers List' > > Subject: RE: Webapp classloader question. > > > > > > you want to put the one from endorsed into server/lib, then > > put yours in > > WEB-INF. This way only one is visible to any tree of the > > classloader. But > > I'm not sure if you will still end up with the JDK version > > since the one in > > WEB-INF is not "endorsed" to override it. > > > > The other thing I would try is to put your version in > > /common/endorsed with > > the tomcat version in /server/lib. > > > > btw, have you just tried replacing the version in /endorsed > > with your newer > > one? > > > > Charlie > > > > > -----Original Message----- > > > From: Lee, William [mailto:[EMAIL PROTECTED] > > > Sent: Thursday, October 09, 2003 4:54 PM > > > To: 'Tomcat Developers List' > > > Subject: RE: Webapp classloader question. > > > > > > > > > This won't work since, all jar files in commons/lib, > > > commons/endorsed, and > > > commons/classes are all visible to the tomcat's "commons" > > > classloader. So, > > > there is no difference whether we put the xerces jar files > > in "lib" or > > > "endorsed", the one from webapps will be skipped. > > > > > > I think the question boiled down to, if we have Xerces on > > > both "endorsed" > > > and "webapps", which one should be used? For tomcat, I would > > > thought that > > > the order for class searching will be "webapps", "shared", "commons" > > > (including "endorsed"), then "system". > > > > > > I believed tomcat put "endorsed" before "system" is to > > > follows the "endorsed > > > classloading spec.". But I also believed forcing delegate > > > model for xerces > > > and xalan maybe overkill? > > > > > > Indeed, the tomcat's "class-loader-howto" document also > > > indicated that the > > > one from webapps should be used instead. > > > > > > Frankly speaking, I'm no expert on these topics, so please > > > feel free to > > > correct me if I mis-understanding anything here. > > > > > > Thanks. > > > William. > > > > > > -----Original Message----- > > > From: Shapira, Yoav [mailto:[EMAIL PROTECTED] > > > Sent: Thursday, October 09, 2003 12:44 PM > > > To: Tomcat Developers List > > > Subject: RE: Webapp classloader question. > > > > > > > > > > > > Howdy, > > > Tomcat 4.1.x implements the endorsed classloader spec. It's > > > compliant with > > > the Servlet Specification v2.3. What you can do if you want > > > your webapp to > > > use the latest xerces/JAXP, is: > > > - Move $CATALINA_HOME/common/endorsed/* to $CATALINA_HOME/common/lib > > > - Put your later xerces etc. in WEB-INF/lib as you've been doing. > > > > > > Yoav Shapira > > > Millennium ChemInformatics > > > > > > > > > >-----Original Message----- > > > >From: Lee, William [mailto:[EMAIL PROTECTED] > > > >Sent: Thursday, October 09, 2003 12:38 PM > > > >To: [EMAIL PROTECTED] > > > >Subject: Webapp classloader question. > > > > > > > > > > > >Hi all, > > > > > > > >I'm not sure if this message reaches you guys yet, so here > > > it go again. > > > >Sorry for any inconvenience if you receiving this message twice. > > > > > > > >Thanks. > > > >William. > > > > > > > >-----Original Message----- > > > >From: Lee, William [mailto:[EMAIL PROTECTED] > > > >Sent: Tuesday, October 07, 2003 3:55 PM > > > >To: '[EMAIL PROTECTED]' > > > >Subject: Webapp classloader question. > > > > > > > > > > > >Hi all, > > > > > > > >When moving from tomcat 4.0.x to 4.1.x, we discovered that the > > > >WebappClassLoader.java had been changed such that all classes from > > > >"org.apache.xerces" and "org.apache.xalan" are forced to be loaded > > > using > > > >the > > > >delegate model first, before looking into the webapp > > directory. This > > > seems > > > >to related to the JDK 1.4 support of the xml and xslt parser. > > > > > > > >However, after a long conversation with the Sun's Java engineer, he > > > point > > > >out that, even JDK 1.4 shipped with the default xml and > > xslt parser, > > > >application server and servlet container should continue to > > > use the one > > > >provided from the webapp directory as described in the > > servlet spec. > > > 2.3. > > > > > > > >Could someone please hint some lights on why tomcat 4.1.x > > decided to > > > >enforce the delegate model for these two packages? > > > > > > > >(The reason I'm asking is that, we try to use the latest > > > Xerces in our > > > >webapps, and since it always look and found the one from > > > common/endorsed > > > >directory, our latest version will always be skipped.) > > > > > > > >Thanks in advance for your help. > > > >William. > > > > > > > >Join us at Cognos' biggest event of the year Enterprise 2003, The > > > Cognos > > > >Business Forum. Taking place in over 25 cities around the > > > world, it's > > > an > > > >opportunity for Business and IT leaders to learn about > > > strategies for > > > >driving performance. Visit > > http://www.cognos.com/enterprise03 for more > > >details. > > > > > >This message may contain privileged and/or confidential information. > > If > > >you > > >have received this e-mail in error or are not the intended recipient, > > you > > >may not use, copy, disseminate or distribute it; do not open any > > >attachments, delete it immediately from your system and notify the > > sender > > >promptly by e-mail that you have done so. Thank you. > > > > > > > > This e-mail, including any attachments, is a confidential business > > communication, and may contain information that is > > confidential, proprietary > > and/or privileged. This e-mail is intended only for the > > individual(s) to > > whom it is addressed, and may not be saved, copied, printed, > > disclosed or > > used by anyone else. If you are not the(an) intended > > recipient, please > > immediately delete this e-mail from your computer system and > > notify the > > sender. Thank you. > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > Join us at Cognos' biggest event of the year Enterprise 2003, > > The Cognos > > Business Forum. Taking place in over 25 cities around the > > world, it's an > > opportunity for Business and IT leaders to learn about strategies for > > driving performance. Visit http://www.cognos.com/enterprise03 for more > > details. > > > > This message may contain privileged and/or confidential > > information. If you > > have received this e-mail in error or are not the intended > > recipient, you > > may not use, copy, disseminate or distribute it; do not open any > > attachments, delete it immediately from your system and > > notify the sender > > promptly by e-mail that you have done so. Thank you. > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > Join us at Cognos' biggest event of the year Enterprise 2003, > > The Cognos > > Business Forum. Taking place in over 25 cities around the > > world, it's an > > opportunity for Business and IT leaders to learn about strategies for > > driving performance. Visit http://www.cognos.com/enterprise03 for more > > details. > > > > This message may contain privileged and/or confidential > > information. If you > > have received this e-mail in error or are not the intended > > recipient, you > > may not use, copy, disseminate or distribute it; do not open any > > attachments, delete it immediately from your system and > > notify the sender > > promptly by e-mail that you have done so. Thank you. > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
