On Fri, Dec 30, 2011 at 3:27 PM, William G. Thompson, Jr. <[email protected]>wrote:
> On Fri, Dec 30, 2011 at 2:33 PM, Scott Battaglia > <[email protected]> wrote: > > On Fri, Dec 30, 2011 at 2:25 PM, William G. Thompson, Jr. < > [email protected]> > > wrote: > >> > >> On Fri, Dec 30, 2011 at 1:54 PM, Scott Battaglia > >> <[email protected]> wrote: > >> > On Fri, Dec 30, 2011 at 1:43 PM, William G. Thompson, Jr. > >> > <[email protected]> > >> > wrote: > >> >> > >> >> On Fri, Dec 30, 2011 at 10:59 AM, Scott Battaglia > >> >> <[email protected]> wrote: > >> >> > On Thu, Dec 29, 2011 at 6:50 PM, William G. Thompson, Jr. > >> >> > <[email protected]> > >> >> > wrote: > >> >> >> > >> >> >> On Thu, Dec 29, 2011 at 1:23 PM, Scott Battaglia > >> >> >> <[email protected]> wrote: > >> >> >> > Bill, thanks for bringing the discussion to the list. What are > the > >> >> >> > ramifications for people who upgrade their CAS version but had > >> >> >> > never > >> >> >> > before > >> >> >> > modified their log4j settings in the web.xml or for those who > >> >> >> > previously > >> >> >> > modified the web.xml? > >> >> >> > >> >> >> Folks who have never modified the log4j settings in web.xml would > >> >> >> see > >> >> >> no > >> >> >> change. > >> >> > > >> >> > > >> >> > The assumption here would be that they also never modified > >> >> > cas.properties, > >> >> > otherwise they would have to update the cas.properties. I didn't > see > >> >> > any > >> >> > defaults set on the property placeholder configurer to make sure > that > >> >> > they > >> >> > don't have a failure. > >> >> > >> >> Defaults could be added to log4jConfiguration.xml. Currently, the > >> >> defaults are in cas.properties, I'd still want sample override config > >> >> in the cas.properties. Given that this is targetted for 3.5, the > >> >> release notes would also point out the change in order to help > protect > >> >> against failure. > >> > > >> > I think you're misunderstanding me (or I'm not saying it wel). If > >> > someone's > >> > never touched any logging settings, in my opinion, they shouldn't have > >> > to do > >> > anything during the upgrade. > >> > >> An upgrade that requires little to no change would be consistent with > >> a point release like 3.4.x. For a minor release like 3.5, the release > >> strategy provides room for moderate changes with commensurate > >> benefits. I'm targeting this improvement for 3.5. > > > > > > I'm pretty sure that if someone's never touched the log settings, they > > aren't seeing any benefit here. > > Well, it's hard to conceive of a production deployment where someone > hasn't had to touch the log settings. > > I've seen it. Its not as uncommon as you would probably think. > >> > >> > At this point, if you don't added defaults to > >> > the property placeholder configurer, at a minimum they will need to > >> > touch > >> > their cas.properties. > >> > >> True. > >> > >> > >> > If you add the default to the log4jConfiguration.xml > >> > file directly then everyone who wants to externalize those would then > >> > need > >> > to override that file. > >> > >> Not true. They would override the log4j init setting in cas.properties. > > > > > > Unless you're adding a second property placeholder here that references > the > > same cas.properties file, how do you plan on adding the defaults if they > > aren't hard-coded in the bean definition? > > > > Maybe the easiest way to demonstrate would be to update the pull request > > with your proposed way of handling defaults? Rather than us go back and > > forth probably saying the same thing differently. > > > https://github.com/wgthom/cas/commit/853f98104d807def353d99d5a77bdd038c58a792 > > defaults in log4jConigruation.xml, overrides in cas.properties. > > I like it. Learned something new too. Wasn't familiar with the Spring 3 syntax. I would have probably either used Daniel's method to keep all the values together or placed them directly as defaults on the bean definition for propertyplaceholder configurer. We should have a strategy for the best way to handle these new properties, as I'm sure more clean up down the line will necessitate it. Maybe a new thread though? Cheers, Scott > Bill > > -- > You are currently subscribed to [email protected] as: > [email protected] > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-dev > > -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
