No. I started with your branch (which had nothing in web.xml for logging) and then disabled the log4j Spring configuration file. It still read it from the file on the classpath (at application startup, since it affected the Spring log output).
I grepped the entire WAR file for log4j. On Fri, Dec 30, 2011 at 1:44 PM, William G. Thompson, Jr. <[email protected]>wrote: > No, I don't think so. Do you have log4j init in two places? > > > On Fri, Dec 30, 2011 at 10:54 AM, Scott Battaglia > <[email protected]> wrote: > > Does it pick up both of them? I was seeing logging statements at the > level > > set by the log4j.xml on the classpath before the log4j initializer was > > loaded. > > > > > > On Thu, Dec 29, 2011 at 7:01 PM, William G. Thompson, Jr. < > [email protected]> > > wrote: > >> > >> I'm not seeing that behavior with https://github.com/Jasig/cas/pull/22. > >> > >> I have the old log4j.xml in the classpath and when I specify a > >> filesystem path in cas.properties it picks up that one as expected. > >> > >> Tomcat-6.0.32, no special config. > >> > >> Bill > >> > >> > >> On Thu, Dec 29, 2011 at 2:22 PM, Scott Battaglia > >> <[email protected]> wrote: > >> > For my own curiosity, I was attempting to test the logging > capabilities. > >> > I > >> > noticed that in Tomcat 6, *regardless* of the log4j configuration in > the > >> > Spring XML, the log4j.xml on the classpath is always loaded. > >> > > >> > How did I notice this? I could manipulate the log level of messages > >> > returned that appeared BEFORE the new Spring bean was > loaded/configured. > >> > I > >> > also was able to completely disable the XML file (renaming it to .bak) > >> > and > >> > make sure the web.xml didn't have any log4j stuff in it and the > >> > log4j.xml > >> > was still loaded. > >> > > >> > So two questions: > >> > 1. Is this a Tomcat configuration problem on my end (I'm pretty sure I > >> > always just unzip the Tomcat and don't do much else to it) > >> > 2. Does this mean that the log4j.xml in the classpath is always being > >> > loaded, plus whatever is configured elsewhere? > >> > > >> > Thanks > >> > Scott > >> > > >> > > >> > 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? > >> >> > >> >> 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. > >> >> > >> >> 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. > >> >> > >> >> 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
