Re: Tomcat classloading...a theory question..
Dear Mathew, Thanks for the link. http://jakarta.apache.org/tomcat/tomcat-5.0-doc/class-loader-howto.html I am afraid I dont understand the paragraph below, regarding the class patterns In addition, for the following class patterns, the classloader will always delegate first (and load the class itself if no parent classloader loads it) = As mentioned above, the web application class loader diverges from the default Java 2 delegation model (in accordance with the recommendations in the Servlet Specification, version 2.3, section 9.7.2 Web Application Classloader). When a request to load a class from the web application's WebappX class loader is processed, this class loader will look in the local repositories first, instead of delegating before looking. There are exceptions. Classes which are part of the JRE base classes cannot be overriden. For some classes (such as the XML parser components in JDK 1.4+), the JDK 1.4 endorsed feature can be used (see the common classloader definition above). In addition, for the following class patterns, the classloader will always delegate first (and load the class itself if no parent classloader loads it): javax.* org.xml.sax.* org.w3c.dom.* org.apache.xerces.* org.apache.xalan.* = Can I put the above class pattern in my WEB-INF/lib path or not ? regards Ben - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat classloading...a theory question..
Hi, javax.* org.xml.sax.* org.w3c.dom.* org.apache.xerces.* org.apache.xalan.* Can I put the above class pattern in my WEB-INF/lib path or not ? You can, but those JARs will be ignored as they have already been loaded from an endorsed location. Here's a short summary of my two cents to go on top of the classloader how-to which you've already read: - Putting stuff in jre/lib/ext is evil and people should be fired for doing it ;) - Putting stuff in common/endorsed is dangerous but sometimes permissible, the notable cases being to use later versions of classes in the above packages. For example, if you want a recent version of Xalan, you must put it in common/endorsed. Thankfully provides like Xerces and Xalan are doing a much better job recently to split impl and API, so that you can put the impl jars in WEB-INF/lib and not worry about endorsed stuff. Other than these special cases, don't put anything in common/endorsed. - Putting stuff in common/lib is only sometimes worth it. Usually, it's better to keep it in WEB-INF/lib so that you can keep your webapp self-contained. Some people like to use server-managed connection pooling and other resources, and it's sort of the J2EE way. But give careful consideration to packaging your own. Things like DBCP are trivial to use in your own webapp, don't automatically use stuff in common/lib just because it's there. The argument of I don't want N versions of my xxx.jar all over the place is naïve at best: disk space is cheap, self-containment is extremely valuable, and you should have rudimentary configuration management in place to be able to deploy/redeploy from scratch in a reproducible manner. This applies to one developer working on his free time in the middle of the night as much as it does to a huge company I think. Yoav 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: Tomcat classloading...a theory question..
.5 additional cents: JNI also drives the use of common/lib, due to the restriction of only loading a native class in one ClassLoader. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat classloading...a theory question..
Yoav, I could not agree with you more! I think a lot of people are abusing comon/lib (and shared/lib) and learning this lesson the hard way (like I have). Hopefully, your advice will help others learn it the easy way! :-) We have tried so many clever schemes to make sure that we have only one copy of x.jar and every single one of them have bitten us in the butt so many times that it hurts to sit down. ;-) Lately, we have started putting everything that we can in the web app, and only what we *absolutely must* in common/lib, and it has made everyone's life s much simpler. Whenever I can update a jar in application A without breaking application B and getting a call at 3am, it is a good thing. Whenever I can manage the movement of a jar from development, to test, then to production independent of all other applications, it is a good thing. Larry [EMAIL PROTECTED] 10/21/2004 8:22:32 AM Hi, javax.* org.xml.sax.* org.w3c.dom.* org.apache.xerces.* org.apache.xalan.* Can I put the above class pattern in my WEB-INF/lib path or not ? You can, but those JARs will be ignored as they have already been loaded from an endorsed location. Here's a short summary of my two cents to go on top of the classloader how-to which you've already read: - Putting stuff in jre/lib/ext is evil and people should be fired for doing it ;) - Putting stuff in common/endorsed is dangerous but sometimes permissible, the notable cases being to use later versions of classes in the above packages. For example, if you want a recent version of Xalan, you must put it in common/endorsed. Thankfully provides like Xerces and Xalan are doing a much better job recently to split impl and API, so that you can put the impl jars in WEB-INF/lib and not worry about endorsed stuff. Other than these special cases, don't put anything in common/endorsed. - Putting stuff in common/lib is only sometimes worth it. Usually, it's better to keep it in WEB-INF/lib so that you can keep your webapp self-contained. Some people like to use server-managed connection pooling and other resources, and it's sort of the J2EE way. But give careful consideration to packaging your own. Things like DBCP are trivial to use in your own webapp, don't automatically use stuff in common/lib just because it's there. The argument of I don't want N versions of my xxx.jar all over the place is naïve at best: disk space is cheap, self-containment is extremely valuable, and you should have rudimentary configuration management in place to be able to deploy/redeploy from scratch in a reproducible manner. This applies to one developer working on his free time in the middle of the night as much as it does to a huge company I think. Yoav 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: Tomcat classloading...a theory question..
http://jakarta.apache.org/tomcat/tomcat-5.0-doc/class-loader-howto.html Ben Bookey wrote: Dear List, Which packages would normally be used by an app. running on Tomcat 4 and Tomcat 5, if identical packages are placed in the paths, i) common\lib ii) mywebapp\WEB-INF\lib iii) jre\lib\ext (Java-Run-Time) It would be logical to me that the version in the app WEB-INF\lib directory would be used 'first' before the TC ClassLoader looks into the common lib. I have been responsible for the dev of an wepapp. which often runs alongside other apps. To avoid the bugs that the customers often have, I would like to put ALL the trouble jar files (in my case the xml parser api jar files), inside my webapp and these will be hopefully used by my app. rather than it using possibly older versions that have been placed inside of the common/lib or even the jre\lib path. I would really appreciate any insight. regards Ben Bookey - 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]
Re: Tomcat classloading...a theory question..
On Wed, Oct 20, 2004 at 06:42:40PM +0200, Ben Bookey wrote: : I have been responsible for the dev of an wepapp. which often runs alongside : other apps. To avoid the : bugs that the customers often have, I would like to put ALL the trouble jar : files (in my case the xml parser api jar files), inside my webapp and these : will be hopefully used by my app. rather than it using possibly older : versions that have been placed inside of the common/lib or even the jre\lib : path. : : I would really appreciate any insight. If at all possible, run separate (unrelated) webapps in separate containers (JVMs). Such isolation limits the impact of one rogue app on the others. -QM -- software -- http://www.brandxdev.net tech news -- http://www.RoarNetworX.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
