Scott Battaglia wrote: > Is there a reason you decided to use Spring 1.2.8 instead of the Spring > 2.0.x that is shipped with CAS? I'm just curious.
Yes, somehow to avoid too many versions flying around in our repository and minimize interop issues for the time being. We have all our applications using Spring 1.2.8 ATM, I waited to have a stable release of Spring 2.x, gave a try to 2.0.2 and one application started to migrate (successfully), and I had all my applications around CAS (ie: CAS, the account management webapp and the sample) starting using 2.0.2 but somehow the bugs I found in the remoting were blocker enough for me to prevent a full migration of our applications to 2.0.2, I could fallback to 2.0.1 eventually, but did not want to potentially go through the same hoops have interops issues with 2.0.1 communicating to 1.2.8 or vice versa. I'm still waiting for 1.2.9 and 2.0.3 :) 1.2.9 was supposed to be on the 9th, but apparently not. I use a pretty special configuration overall as I decided to abstract the datastore from CAS for the time being. CAS is communicating via https (serialized objects) to the AMS (Account Management) webapp which expose the UserDetailsService of Acegi. CAS/Acegified webapps as well use this service entry point. The Acegi ACLs dao is exposed that way too. The motivation behind that is that the datastore (sql for now) and the schema is not finalized(lots of things moving around) so at least I have some amount of flexibility in messing around while the interface to applications stays very simple and is limited solely to the Acegi API. I thus have no specific dependencies and decrease possibilities of breakage. -- stephane _______________________________________________ Yale CAS mailing list [email protected] http://tp.its.yale.edu/mailman/listinfo/cas
