[cas-dev] easier configuration in CAS 3.1.2-SNAPSHOT

[Arnaud Lesueur]

I do not see the point of splitting the deployerConfigContext.xml. For me,
if we split this file the idea will be to provide one file per handler. But,
with current architecture, we are not able to do so (I guess spring does not
allow it).

By the way, I think in cas-servlet, cookie beans (warnCookieGenerator and
ticketGrantingTicketCookieGenerator) should be in a specifc file. A deployer
might have to change :
- lifetime session
- domain and path of the cookie

I'm right now thinking also of the login webflow stuff. While it can be
customized in serveral cases :
- for handlers such as spnego, x509, trusted ...
- redirect end view through a page instead of an HTTP Redirect

Before the next release, we should also commit specific configuration files
into unused-spring-configuration. There shoule be at least actions
definitions for handlers and ticket repositories examples.

My 0.0135 €

-Arnaud


On Jan 31, 2008 8:49 PM, Scott Battaglia <scott.battaglia at gmail.com> wrote:

> Thanks, Matt!
>
> Anyone else have any thoughts on splitting up the
> deployerConfigContext.xml or not (I'm leaning against it considering all
> the documentation that references it).
>
> -Scott
>
> On Jan 31, 2008 12:06 PM, Smith, Matt <matt.smith at uconn.edu> wrote:
>
> > > 1. whether the split of the files currently in the configuration
> > > directory in Subversion is sufficient (of if we should be more
> > > fine-grained)
> >
> > The granularity is appropriate -- much more granular, and you'll have
> > one file for each attribute/value pair.  Your current breakdown seems to
> > successfully reflects one file per common point of extension.
> >
> > > 2. whether we should split up the deployerConfigContext.xml also.
> >
> > It may be useful to split the wiring up here, but not necessary.  For
> > example, I only modify the "authenticationHandlers" property of
> > AuthenticationManager, and the "attributeRepository" bean is rather
> > unrelated, so these could be separated.  But, #1 by itself is a great
> > step forward.
> >
> > > If we do #2, then we'll definitely need to do a 3.2 release instead of
> > > 3.1.2.  Its still up in the air right now whether these configuration
> > > changes and addition of the Stats/auditing tool are sufficient for a
> > > 3.2 release.  Opinions?
> >
> > Nope -- they're just numbers to me. :)
> >
> > -Matt
> >
> >
> >
> >
> > --
> > Matt Smith
> > matt.smith at uconn.edu
> > University Information Technology Services (UITS)
> > University of Connecticut
> > PGP Key ID: 0xE9C5244E
> >
> > _______________________________________________
> > cas-dev mailing list
> > cas-dev at tp.its.yale.edu
> > http://tp.its.yale.edu/mailman/listinfo/cas-dev
> >
> >
>
>
> --
> -Scott Battaglia
>
> LinkedIn: http://www.linkedin.com/in/scottbattaglia
>
> _______________________________________________
> cas-dev mailing list
> cas-dev at tp.its.yale.edu
> http://tp.its.yale.edu/mailman/listinfo/cas-dev
>
>


-- 
Arnaud Lesueur

LinkedIn: http://www.linkedin.com/in/lesueur
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://tp.its.yale.edu/pipermail/cas-dev/attachments/20080201/1973201e/attachment.html