You have a few options: 1. Exclude those jars when you build the CAS war file (using standard Maven methods) and hope that CAS works when you deploy it 2. Isolate CAS into its own container instance such that there are no shared jars 3. Don't deploy shared libraries that may not be consistent across applications (i.e. generally db drivers are okay, but not necessarily Spring jars where applications that depend on them may be on different upgrade cycles).
-Scott On Tue, Feb 10, 2009 at 4:25 PM, Bruno Melloni <[email protected]>wrote: > > Yes, WARs are classpath isolated, but not necessarily classloader > isolated. Meaning that if a class only exists on war 1 but not on 2, 2 > cannot load it... but, if the class exists on both but with different > versions, I seem to remember (from past experience) that the first > instance of the class to load is the one used across the board. > > This may be server-specific, but I don't remember encountering a server > yet where WARs were classloader isolated. > > For EARs I know that the likelihood of isolation is much greater, and > often configurable depending on the server. > > So, the question remains: Is there a strategy that is recommended to > ensure that CAS' dependent libraries don't conflict with what's on the > server or other apps - especially in servers like jBoss where the use of > unified classloaders (even across EARs) is prevalent. > > bruno > > -----Original Message----- > From: Keith Garry Boyce [mailto:[email protected]] > Sent: Tuesday, February 10, 2009 1:16 PM > To: [email protected] > Subject: RE: [cas-user] Dependent library version conflicts - > recommended strategy? > > Wars are class path isolated > > -----Original Message----- > From: Bruno <[email protected]> > Sent: Tuesday, February 10, 2009 1:09 PM > To: [email protected] > Subject: [cas-user] Dependent library version conflicts - recommended > strategy? > > I just installed the sample pre-built CAS WAR, which works fine, and I'm > about to build/configure so that I can tie it to my apps and > ActiveDirectory. > > I noticed that being deployed as a WAR, it will share the classloader in > Tomcat (or jBoss) with other webapps. Since it contains JARs for > spring, spring security and others, there is a potential for version > conflicts. For example, we currently use spring 2.0.7 and > spring-security 2.0.4 instead of spring 2.5.6 and spring-security 2.0.3 > included in the cas distribution. > > Is there a recommended strategy to avoid such conflicts? (other than > instantly changing the library versions used by all of our apps - not > feasible) > -- > You are currently subscribed to [email protected] as: > [email protected] > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-user > > > -- > You are currently subscribed to [email protected] as: > [email protected] > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-user > > -- > You are currently subscribed to [email protected] as: > [email protected] > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-user > -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
