The Log4J documentation appears a bit conflicted on whether that should happen (or its just so poorly written when I checked the other day, I couldn't tell). If that's the case though, it will means that with log4j.xml on the classpath it will load that when the application starts. I saw this behavior even with the Spring configured log4j (though I don't know how the Spring configured log4j affected the initial loading).
If the default is to read from the classpath on JVM start up, then we'll need to move the log4j configuration out of the classpath. If you've got your set up in place, can you quickly try something: 1. in the log4j.xml on the classpath, set the org.springframework to TRACE 2. in the log4j.xml that you've externalized, set it to ERROR or FATAL See what gets outputted. In theory, if it works correctly, you should see nothing before the log4j thing is initialized, and even after that very minimal since its on ERROR or FATAL. If it loads the classpath one, you'll see some trace stuff before log4j is initialized by Spring, but I'm not sure what will happen after. Cheers, Scott On Fri, Dec 30, 2011 at 1:52 PM, William G. Thompson, Jr. <[email protected]>wrote: > Thats default log4j behavior...if it doesn't find instructions on how > to find its config file it falls back on a default algorithm that > includes the classpath. > > > On Fri, Dec 30, 2011 at 1:48 PM, Scott Battaglia > <[email protected]> wrote: > > 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 > > -- > 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
