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. > 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. > > The Property Placeholder Configurer in the pull request should have the > defaults in order to mitigate this issue. I'm not opposed to adding defaults to log4jConfiguration.xml. >> >> >> >> Folks who previously had to manage web.xml in the maven overlay simply >> >> to externalize log4j.xml would no longer have to. >> > >> > Yes, and they would need to revert their web.xml, update the >> > cas.properties >> > file (if they've modified it). Otherwise, the log4j settings would be >> > loaded twice? Is that correct? >> >> The web.xml would no longer be needed in the maven overlay. log4j >> settings would be loaded once from the location specified in >> cas.properties (or potentially from defaults in >> log4jConfiguration.xml). > > > Yes, I understand that. But if its there they would need to be told to > remove it. Otherwise their settings would be loaded twice. > > Since there is documentation committed to the repository, can you add an > upgrading section and include the various steps deployers would need to take > to upgrade CAS with these new changes, this way it can be reviewed along > with the other changes? The short of it is, folks upgrading to 3.5 who currently manage there log4j settings on the classpath will see no change in behavior. If they have a modified web.xml in their overlay they will have to sync it with the release. Otherwise there is no impact. I'm happy to contribute to any release notes or upgrade instructions once the new approach is in master. 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
