On Fri, Dec 30, 2011 at 1:59 PM, Scott Battaglia <[email protected]> wrote: > 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.
Not necessary. The fallback algorithm for searching for a log4j.xml will only kick in if one is not supplied in configuration. > > 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. I've re-verified that the log4j.xml file left on the classpath from the default distribution does not conflict with the log4j.xml file specified in configuration. Bill > > 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 -- 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
