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

Reply via email to