RE: Webapp classloader question.
I too had a problem loading XML libraries under tomcat 4.1. I thought I identified the problem and reported bug 16577. See http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16577 I proposed a simple fix, but alas, Remy Maucherat, thought the delegation model worked as intended and WONTFIXed it. The upshot is that classes with the following package prefixes are loaded by the parent loader: javax, // Java extensions org.xml.sax, // SAX 1 2 org.w3c.dom, // DOM 1 2 org.apache.xerces, // Xerces 1 2 org.apache.xalan // Xalan As xalan and xerces are in this list (taken from the source code), you can't load your own version of these libraries without modifying the source. -Babak --- Lee, William [EMAIL PROTECTED] wrote: 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
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
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
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
RE: Webapp classloader question.
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
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
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
RE: Webapp classloader question.
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
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]
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.
