On Wed, Jan 11, 2012 at 4:39 PM, Andrew Petro <ape...@unicon.net> wrote:
> Deliberately forking this thread, since I don't want this detail to > distract from discussion about the general approach. > > > Bill, > > I have a (possibly irrational) fear of this bit: > > > * Move the propertyFileConfigurer configuration block into > > deployerConfigContext.xml (minimize config files) > > I vaguely remember having found it handy that the property file configurer > *isn't* in deployerConfigContext.xml. I'll either figure out where I > tripped over this and report back, or please ignore my hand wringing with > my apologies for the thrash. > I don't know if it really breaks anything so much as you want to keep things in there that you really expect deployers to modify (because otherwise if you have to change/adjust it, people have to then do it in their file which they are pretty much guaranteed to have changed). Cheers, Scott > > Andrew > > > > On Jan 11, 2012, at 3:35 PM, William G. Thompson, Jr. wrote: > > > I'd like to move forward on this for 3.5 and it seems like we might > > have come to some consensus. I've restated the proposal below with > > the addition of robust sample config in cas.properties. Could I get a > > straw vote (including non-committers) on the following: > > > > CAS Configuration Principles > > * Simple should be easy, complex should be possible > > * Key config should be easily externalized so that a single war file > > can easily be deployed to multiple tiers or nodes > > * Consistent approach > > * Generally seek to limit the number of files that need to be managed > > in the overlay to make upgrading easier. > > > > Approach > > * Push all defaults to the bean files where they are defined inline > > using the Spring 3.x approach and continue to use cas.properties as > > the deployment override file for simple parameter configuration. > > (simple should be easy) > > > > * Continue to use deployerConfigContext for the rest of a typical > > deployer config (simple should be easy) > > > > * Continue the use of bean xml file override for more complex behavior > > configuration (complex is possible) > > > > * Create new property placeholders and defaults for bean properties > > that could benefit from the new approach (e.g. SSO Session timeouts, > > SLO on/off). (minimize the number of files that need to be managed in > > the overlay) > > > > * Move the propertyFileConfigurer configuration block into > > deployConfigContext.xml (minimize config files) > > > > * Provide robust sample config in cas.properties for all of the > > properties that a deployment might want to override in the simple > > case. (consistent approach) > > > > Bill > > > -- > You are currently subscribed to cas-dev@lists.jasig.org as: > scott.battag...@gmail.com > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-dev > > -- You are currently subscribed to cas-dev@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
