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.


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

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

Reply via email to