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. >> >> > 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. 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
