On Thu, Jan 12, 2012 at 12:31 AM, Daniel Frett <daniel.fr...@ccci.org> wrote: > I may be wrong, but I remember encountering an issue with my maven overlay, > which defined an additional servlet that to fix I had to explicitly load > propertyFileConfigurer.xml even though all the other beans defined in > deployerConfigContext were present. > > I believe it is related to how bean contexts are layered on top of each other > for servlets and how PropertyPlaceholderConfigurer works. > > PropertyPlaceholderConfigurer works via the BeanFactoryPostProcessor > interface, which only applies to the bean context it is directly loaded in > and not to any children context that inherit from the parent context. This > matters with servlets because there is a global context that the majority of > the cas beans are loaded in, and then there is the servlet context which > inherits from the global context and defines some additional local beans. > > So, merging propertyFileConfigurer.xml into deployerConfigContext.xml would > mean 1 of 2 things, > 1. cas-servlet.xml would have to explicitly load deployerConfigContext even > though all the beans were already loaded in the global scope. or > 2. cas-servlet.xml could no longer use property placeholders (There are > currently several placeholders in cas-servlet.xml) >
Andrew, Daniel, Thanks for the feedback. Moving this bit of config is the least of my concerns and I'll be happy to leave it where it is if this turns out to be a real issue. Best, Bill > -Daniel > > On Jan 11, 2012, at 4:45 PM, Scott Battaglia wrote: > > On Wed, Jan 11, 2012 at 4:39 PM, Andrew Petro > <ape...@unicon.net<mailto: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<mailto:cas-dev@lists.jasig.org> as: > scott.battag...@gmail.com<mailto: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<mailto:cas-dev@lists.jasig.org> as: > daniel.fr...@ccci.org<mailto:daniel.fr...@ccci.org> > 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: wgt...@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
