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

Wed Jan 30 21:18:21 EST 2008

Agree.

We were always struggling on how to separate "our" configurations from the
"original" cas, in order to facilitate version upgrade. It's better not only
xml files can be overrided, but also those properties files. (or possibly
move all the properties files into xml)

However, I think this change should be made more clear enough to deployers.
A "minor" change may lead to confusion if people not really reads the
discussion here and README files regularly. The only consequence is many
people asking the same question in the group.

My HKD7.79 (Hong Kong dollars is linked to USD and never change... -_-")

Harry

Arnaud Lesueur-4 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€ ;-)
> 
> -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
> 
> 

-- 
View this message in context: http://www.nabble.com/easier-configuration-in-CAS-3.1.2-SNAPSHOT-tp15186861p15196858.html
Sent from the CAS Dev mailing list archive at Nabble.com.