alternatively you can unpack the jar files, delete the older conflicting classes, and repackage to avoid these conflicts. I've had to do this on occasion.
Charlie > -----Original Message----- > From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, July 17, 2002 2:49 PM > To: Tomcat Users List > Subject: Re: explicit ordering of jars searched by classloader in web > application > > > > > On Wed, 17 Jul 2002, Tait E Larson wrote: > > > Date: Wed, 17 Jul 2002 10:56:24 -0700 > > From: Tait E Larson <[EMAIL PROTECTED]> > > Reply-To: Tomcat Users List <[EMAIL PROTECTED]> > > 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? > > > > If there was such a configuration option (and there's not) it would be > defined in the Servlet Specification > <http://java.sun.com/products/servlet/download.html>. > > The only promise you get is that classes in "WEB-INF/classes" will be > loaded in preference to classes from JAR files in > "WEB-INF/lib". For the > individual JAR files in "WEB-INF/lib" directory, that is > totaly up to the > container (and may not even be in the container's control if > you run your > webapp from an open directory the way that Tomcat lets you do it). > > IMHO, application designs that rely on this kind of thing are > incredibly > fragile, because they rely on this sort of an internal > detail. I'd look > for libraries that let you configure which implementation of > a particular > API you want (for example, the way that JAXP APIs let you > configure which > parser implementation to use) instead. > > > Thanks, > > > > Tait > > Craig > > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
