> > Let's be clear: both CAS Server and CAS Client are built using Maven2. We > recommend you manage your CAS Server via the Maven2 WAR Overlay process. We > do not control, nor do we recommend a method for which you manage your local > applications which include CAS clients. This is why the CAS client supports > three methods of configuration. If your local application uses Maven2, then > you've got four options :-) Though only the last three are viable options for > maintenance. >
When talking about the filtering that I believe should be added, I was referencing the CAS Server, not the client. Whilst you may not need to modify the web.xml, you almost definitely do need to modify other files like the deployerConfigContext.xml as that contains per-environment specific configuration. The downside of the Maven overlay approach is that you need to maintain multiple copies of the same file. These can get dated and out of sync if a change is made centrally and not merged to your own files on every environment. So we have only one set of source code and that same code is reused in every environment we have and using the maven-war-plugin, substitute the placeholder variables for their real values. It's also much easier than setting up an overlay as all you do is fill in your values in the properties file, build and go. The patch is only about 10 lines if you are interested. And this is the same approach that uPortal is taking with their build. cheers, Steve > > > In both cases, Maven can be used to provide build time filtering and enable > reuse of code on different servers. So I suggested that this be added to the > CAS server by default, since it is useful functionality. > > cheers, > Steve > > > > >> >> >> >> On 02/02/2011, at 10:31 PM, Kristian Rink wrote: >> >> > Folks; >> > >> > so far stumbling into running CAS in our environment, I am stuck with a >> > scenario like this: I do have a Java web application (war package) >> > including a web.xml having all the CAS related filters declared and >> > configured so things work fine. However, right now I end up with >> > configuration like this... >> > >> > [...] >> > <filter> >> > <filter-name>CAS_Authentication_Filter</filter-name> >> > >> > <filter-class>org.jasig.cas.client.authentication.AuthenticationFilter</filter-class> >> > <init-param> >> > <param-name>casServerLoginUrl</param-name> >> > >> > <param-value>http://localhost:8080/auth/login</param-value> >> > </init-param> >> > <init-param> >> > <param-name>serverName</param-name> >> > <param-value>http://localhost:8080/</param-value> >> > </init-param> >> > </filter> >> > [...] >> > >> > ... which is not that nice. The CAS application, generally, is a .war >> > file built using the maven overlay approach and supposed to run in the >> > same servlet container the business application (so far) is running in, >> > and, for testing purposes, I would like to have the CAS and business >> > app run on my local machine (thus "localhost") and, for production >> > environment, I want to be able to deploy the whole configuration >> > (without changing web.xml) to the server. Trying something like >> > >> > [...] >> > <filter> >> > <filter-name>CAS_Authentication_Filter</filter-name> >> > >> > <filter-class>org.jasig.cas.client.authentication.AuthenticationFilter</filter-class> >> > <init-param> >> > <param-name>casServerLoginUrl</param-name> >> > <param-value>/auth/login</param-value> >> > </init-param> >> > <init-param> >> > <param-name>serverName</param-name> >> > <param-value>/</param-value> >> > </init-param> >> > </filter> >> > [...] >> > >> > however failed, and, looking at what happened, it didn't take me twice >> > seeing why. However: Is there a good way of achieving what I would like >> > to do (i.o.w. not hard-coding the serverName in web.xml), or should I >> > use some kind of maven magic and profiles in order to deploy my >> > application right? Comments? >> > >> > TIA and all the best, >> > Kristian >> > >> > -- >> > 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 > > -- > 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
