After a bit of agony, I figured out a bit of a pattern--I think.
If I start tomcat from the command prompt, then I see logging (and the log4j internal debug statements). However, if I run tomcat from the start menu or as an NT service I get no logging. I don't know how to fix this. This indicates to me a resource or timing issue--I think. Can anyone help? -----Original Message----- From: Ceki G�lc� [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 11, 2002 1:40 PM To: Log4J Users List Subject: RE: configuration problem Check that the JVM that launches Tomcat sees your options. Look into catalina.sh or catalina.bat. At 13:38 11.09.2002 -0400, you wrote: >Any suggestions on what to check next? > >-----Original Message----- >From: Ceki G�lc� [mailto:[EMAIL PROTECTED]] >Sent: Wednesday, September 11, 2002 1:30 PM >To: Log4J Users List >Subject: RE: configuration problem > > >debug=true makes log4j emit internal messages. The fact that you are not >seeing any change means that the config file (logconfig.xml) is not being >read. > >At 13:24 11.09.2002 -0400, you wrote: > > >What is the 'debug="true"' supposed to do? > >I did this and did not notice anything different. > > > >Yes, logconfig.xml is in WEB-INF/classes/. > > > >-----Original Message----- > >From: Ceki G�lc� [mailto:[EMAIL PROTECTED]] > >Sent: Wednesday, September 11, 2002 12:57 PM > >To: Log4J Users List > >Subject: Re: configuration problem > > > > > >Looks good to me. Change > > > ><log4j:configuration xmlns:log4j='http://jakarta.apache.org/log4j/'> > > > >to > > > ><log4j:configuration debug="true" > >xmlns:log4j='http://jakarta.apache.org/log4j/'> > > > >and see what happens. > > > >Where have you placed the logconfig.xml file? Is it in WEB-INF/classes/ ? > > > >At 12:56 11.09.2002 -0400, you wrote: > > >When I run my web app I get: > > > > > >log4j:WARN No appenders could be found for logger (DoraLogger). > > >log4j:WARN Please initialize the log4j system properly. > > > > > >I cannot figure out why. I believe I have things configured correctly. > > > >[snip] > > > > > >-- > >Ceki > > > >TCP implementations will follow a general principle of robustness: be > >conservative in what you do, be liberal in what you accept from > >others. -- Jon Postel, RFC 793 > > > > > > > >-- > >To unsubscribe, e-mail: ><mailto:[EMAIL PROTECTED]> > >For additional commands, e-mail: ><mailto:[EMAIL PROTECTED]> > > > > > >-- > >To unsubscribe, e-mail: ><mailto:[EMAIL PROTECTED]> > >For additional commands, e-mail: ><mailto:[EMAIL PROTECTED]> > >-- >Ceki > >TCP implementations will follow a general principle of robustness: be >conservative in what you do, be liberal in what you accept from >others. -- Jon Postel, RFC 793 > > > >-- >To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> >For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > >-- >To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> >For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- Ceki TCP implementations will follow a general principle of robustness: be conservative in what you do, be liberal in what you accept from others. -- Jon Postel, RFC 793 -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
