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

Scott Battaglia scott.battaglia at gmail.com
Thu Jan 31 11:47:00 EST 2008 

I'm hoping to cut the RC release tomorrow.

If you guys can provide feedback on the following, that would be great:
1. whether the split of the files currently in the configuration directory
in Subversion is sufficient (of if we should be more fine-grained)
2. whether we should split up the deployerConfigContext.xml also.

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?

Thanks
-Scott

On Jan 30, 2008 9:18 PM, Harry Ng <harryworld at gmail.com> wrote:

>
> 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.
>
> _______________________________________________
> 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/20080131/23efdc08/attachment.html

More information about the cas-dev mailing list