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

[Scott Battaglia]

On Jan 30, 2008 4:30 PM, Arnaud Lesueur <arnaud.lesueur at gmail.com> wrote:

> Well +1 for me.
>
> I guess this is a great idea. This allows us also to provide a full
> configuration example for each handler instead of current process which is
> to modify existing confiugration. End-user will still have to merge files
> for specific configuration when using several handlers but just for testing
> one specific handler this will be easier to manage.
>
> My 0.02€ ;-)


That's probably worth a lot more than our two cents over here at the current
rate of exchange ;-)

-Scott

>
>
> -Arnaud
>
> On Jan 30, 2008 10:08 PM, Andrew Petro <apetro at unicon.net> wrote:
>
> >  > I'm curious how others feel about this change.
> >
> > Change to auto-detect and honor configuration files in a particular
> > appropriately located not-served-to-the-web directory sound in keeping with
> > the trend towards "convention over configuration".  CAS3 has other
> > convention-over-configuration behaviors, such as the defaults in many beans
> > on which it falls back when particular configuration is not
> > dependency-injected.
> >
> > So, loosely, I feel pretty good about this specific change.
> >
> > Things that make this more palatable include a README in the
> > conventional directory documenting that files dropped in the directory will
> > be parsed and honored, and being really very clear about *when* this
> > happens, what the refresh behavior is if any, and what the failure behavior
> > is (does dropping a malformed file into this directory squib the whole CAS
> > init?  Just drop that file?)
> >
> > I hear the concern that this will be confusing -- that one might drop a
> > new file in that directory, forget that one has done so, and be unpleasantly
> > surprised on next CAS startup, e.g.  I think it's countervailed by
> > having to enumerate these files, potentially get their names wrong, etc.,
> > effectively duplicating configuration (sticking the file in the directory
> > and enumerating the file in web.xml) also being confusing and
> > error-prone in its way.
> >
> > I wouldn't want to go too far down this road of convention over
> > configuration.  Auto-wiring the CAS Spring configuration files sounds a poor
> > idea, a loss to literacy of the configuration.  But this change seems a step
> > towards the right point on the spectrum for CAS.
> >
> > My two cents.
> >
> > Andrew
> >
> >
> >
> >
> >
> > Scott Battaglia wrote:
> >
> > The XML configuration files have to be placed in a specific directory
> > that is under the WEB-INF directory.  The web.xml is configured to only
> > load XML files in that specific directory.  It eliminates the need for every
> > deployer to modify the web.xml.  It also allows us to break out the
> > configuration files into smaller subsets and allow you to override specific
> > ones without having to make a copy of the larger file (i.e.
> > applicationContext.xml).
> >
> > -Scott
> >
> > On Jan 30, 2008 2:22 PM, William G. Thompson, Jr. <wgthom at rutgers.edu>
> > wrote:
> >
> > > Not sure how I feel about loading *.xml files...seems like it could
> > > lead to some unintended consequences.  Isn't it better, safer maybe,
> > > to have these explicitly identified?  I'm curious how others feel
> > > about this change.
> > >
> > > Bill
> > >
> > >
> > > On Jan 30, 2008 11:56 AM, Scott Battaglia <scott.battaglia at gmail.com>
> > > wrote:
> > > > For the first time in a long time, I've actually had to do a
> > > deployment of
> > > > CAS from scratch (shocking, yes, I know).  So its the first time
> > > I've had
> > > > the pleasure of using the WAR overlay method of keeping track of
> > > your
> > > > customizations.  [side note, if you're not using it I recommend it].
> > > >
> > > > However, when using it I noticed a few things that could be done
> > > more
> > > > easily, so I've made a few modifications to the way we handle
> > > configuration
> > > > files:
> > > >
> > > > Except for the files that we reference constantly or need to be in a
> > > > particular spot (I'm looking at you, deployerConfigContext.xml and
> > > > cas-servlet.xml), all other Spring XML configuration files are
> > > either
> > > > located in WEB-INF/spring-configuration/ or
> > > WEB-INF/unused-configuration/
> > > >
> > > > The web.xml is set up to load deployerConfigContext.xml and
> > > > WEB-INF/spring-configuration/*.xml.  You need to add a configuration
> > > file or
> > > > enable one?  Just put it in that directory (preferably using the WAR
> > > overlay
> > > > method).  Some of the things that are more frequently modified have
> > > been
> > > > broken out into their own configuration files.
> > > >
> > > > This is going in for the CAS 3.1.2 release.  If you have any
> > > suggestions on
> > > > breaking up the configuration files some more, etc. please let me
> > > know
> > > > within the next day or two.
> > > >
> > > > Thanks
> > > > -Scott
> > > >
> > > >  --
> > > > -Scott Battaglia
> > >
> >
> > _______________________________________________
> > 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
> _______________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://tp.its.yale.edu/pipermail/cas-dev/attachments/20080130/1e35aab1/attachment.html