Howdy, It's not a good idea to have more than one version of a class visible to the class loader. Various bad things happen, like ExceptionInInitializerError, LinkageError, and NoSuchMethodException and the likes.
One of the reasons tomcat doesn't look at the CLASSPATH environment variable, for example, is to preclude any confusion or problems arising from developers relying on the order of jars in the class path. One possible alternative would be to repackage the 3rd party jars to not contain duplicate classes. I don't like repackaging (or in any way modifying) 3rd party jars, but it's better than writing code to deal with class loading. Out of curiosity, what are the duplicate classes? Are they a common API or your own? If it's a common API, chances are there's already a version of the jar out there repackaged to deal with this situation. Yoav Shapira Millennium ChemInformatics >-----Original Message----- >From: Tait E Larson [mailto:[EMAIL PROTECTED]] >Sent: Wednesday, July 17, 2002 1:56 PM >To: [EMAIL PROTECTED] >Subject: explicit ordering of jars searched by classloader in web >application > >I've got three third party jar files in the WEB-INF/lib directory of my web >aplication that contain different versions of the same classes. I need to >explicitly state the order in which the classloader searches these jars in >order for my web application to work correctly. Can this be done by >manipulating the classloader at runtime? Would it be possible to explicitly >state the jar ordering somewhere in web.xml? > >Thanks, > >Tait > > > >-- >To unsubscribe, e-mail: <mailto:tomcat-user- >[EMAIL PROTECTED]> >For additional commands, e-mail: <mailto:tomcat-user- >[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
