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

[Andrew Petro]

 > 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 
> <mailto: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 <mailto: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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://tp.its.yale.edu/pipermail/cas-dev/attachments/20080130/a9b49390/attachment-0001.html