Hmm... Seems like even the Sun's engineer also have different point of views between them as well... Now, I'm totally confused about which way should be the right way to go...
It there any Sun/Java representative on this mailing list that can answer this question then? Thanks again for all your help. William. -----Original Message----- From: Cox, Charlie [mailto:[EMAIL PROTECTED] Sent: Friday, October 10, 2003 2:38 PM To: 'Tomcat Developers List' Subject: RE: Webapp classloader question. here's one reply that I got a while ago about the issue when it was changed in 4.0.2(saying basically the same thing) http://www.mail-archive.com/[EMAIL PROTECTED]/msg74261.html I know that the WEB-INF classloader changes the delegation model by looking for classes within WEB-INF BEFORE delegating to its parent, but I don't know why the endorsed spec was chosen to override the servlet spec. Charlie > -----Original Message----- > From: Lee, William [mailto:[EMAIL PROTECTED] > Sent: Friday, October 10, 2003 2:13 PM > To: 'Tomcat Developers List' > Subject: RE: Webapp classloader question. > > > To be honest, I got exactly the same impression when I read > this document > half a year ago. However, when I tried to clarify all the > "grey" areas in > this document with Sun, here is the response from their Java engineer: > > *** > The standard "delegation model" used by Java does say that a child > classloader should look first to its parent classloader when searching > for classes. As you know, this model works against us in your > situtation, since > the application classloader for a web app is a child of the > system class > loader (where the 1.4 parsers are loaded). However, the servlet > specification requires that a web app obtain its class > definition from the > WAR file. Therefore, most vendors have implemented a way for the > application classloader to look in the WAR file first before > going to a > parent, thereby overriding the standard delegation model. > *** > > So, it seems to me that the servlet spec. should supersede > the "endorsed > mechanism" in the web application environment. > > William. > > -----Original Message----- > From: Cox, Charlie [mailto:[EMAIL PROTECTED] > Sent: Friday, October 10, 2003 1:17 PM > To: 'Tomcat Developers List' > Subject: RE: Webapp classloader question. > > > 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] 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.
