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 soooo 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]
