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. 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. 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. The Property Placeholder Configurer in the pull request should have the defaults in order to mitigate this issue. > > > >> > >> > >> 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? Thanks Scott > > Bill > > > > > > Cheers, > > Scott > > > >> > >> As part of a minor 3.5 release and consistent with the release > >> strategy, they would also have to adopt the settings in cas.properties > >> when moving from 3.4.x. > >> > >> > > >> > Let's also be clear: this is an alternative to overriding the web.xml > in > >> > your overlay. Both options provided the ability to do what you are > >> > saying > >> > can be done by moving these values to CAS.properties, though web.xml > >> > required copying the file to your overlay. > >> > >> Yes, a core part of the proposal is a better way to externalize > >> log4j.xml so that folks don't have to manage web.xml in the overlay. > >> > >> Folks already have to manage cas.properties so there is no additional > >> burden, in fact the approach simplifies the deployment and makes it > >> easier to upgrade. > >> > >> > >> > > >> > I'm also interested in how you compared whether there was a loss of > >> > logging > >> > or not (I.e. is this initialized first so that if you set spring > logging > >> > to > >> > debug, you will see all the startup debug messages?). Apologies if > that > >> > was > >> > in the JIRA ticket. The emails are a pain to read on the phone. > >> > >> There was no loss of logging in my testing. I compared 3.4.11 vs > >> 3.4.12-snapshot with the alternative logging config patch applied > >> based on the default settings. I also ran with DEBUG with no change. > >> > >> This is with bean config: > >> > >> INFO: Deploying web application directory cas-log > >> 2011-12-29 18:42:39,168 INFO > >> [org.springframework.web.context.ContextLoader] - <Root > >> WebApplicationContext: initialization started> > >> 2011-12-29 18:42:39,199 INFO > >> [org.springframework.web.context.support.XmlWebApplicationContext] - > >> <Refreshing Root WebApplicationContext: startup date [Thu Dec 29 > >> 18:42:39 EST 2011]; root of context hierarchy> > >> > >> This is with web.xml config: > >> > >> 2011-12-29 18:38:28,103 INFO > >> [org.springframework.web.context.ContextLoader] - <Root > >> WebApplicationContext: initialization started> > >> 2011-12-29 18:38:28,127 INFO > >> [org.springframework.web.context.support.XmlWebApplicationContext] - > >> <Refreshing Root WebApplicationContext: startup date [Thu Dec 29 > >> 18:38:28 EST 2011]; root of context hierarchy> > >> > >> Billl > >> l > >> > >> > >> > > >> > On Dec 29, 2011 1:10 PM, "William G. Thompson, Jr." <[email protected] > > > >> > wrote: > >> >> > >> >> Folks, > >> >> > >> >> This is a request for feedback regarding JIRA CAS-1082, Move Log4J > >> >> initialization into Spring bean config so that cas.properties can be > >> >> applied. - https://issues.jasig.org/browse/CAS-1082 > >> >> > >> >> Also see Pull Request: https://github.com/Jasig/cas/pull/22 > >> >> > >> >> I'm proposing this change be included in CAS 3.5 consistent with the > >> >> release strategy: > >> >> https://wiki.jasig.org/display/CAS/CAS+Roadmap > >> >> > >> >> Motivation for this change comes from working with over half a dozen > >> >> CAS deployments over the last year or so. > >> >> > >> >> This approach preserves the default location of > >> >> WEB-INF/classes/log4j.xml while making it very easy for deployers to > >> >> externalize the location via settings in cas.properties. This is > >> >> helpful in multi-node deployments, deployments across multiple tiers, > >> >> and preserving configuration between upgrades. > >> >> > >> >> A comparison of this patch against 3.4.11 showed no loss of logging. > >> >> > >> >> Best, > >> >> 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 > >> > >> -- > >> 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 > > -- > 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
