Servlet not reading log4j.properties

[Ole Christian Langfjaeran]

Closing in on a serious hearloss soon with this problem. According to http://logging.apache.org/log4j/docs/manual.html :
"... you should place the log4j.properties under the WEB-INF/classes
directory of your web-applications. Log4j will find the properties file and initialize itself. This is easy to do and it works."

Well. Doesn't work for me, and I've restarted Tomcat 5.5 so much I can do
it blindfolded soon. Yes, I've installed commons-loggin.jar and
log4-1.2.9.jar in WEB-INF/lib. All logs are still written to
stderr_xxxx.log and no formatting is gathered from the properties file. I
wonder...

my code:
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
public class HandleReportServlet extends HttpServlet{

private static Log logger = LogFactory.getLog(HandleReportServlet.class);

protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException {
logger.warn("Got request");
}
}

Ole C.

 

[Peter Davies]

Closing in on a serious hearloss soon with this problem. According to
http://logging.apache.org/log4j/docs/manual.html : "... you should place
the log4j.properties under the WEB-INF/classes directory of your
web-applications. Log4j will find the properties file and initialize
itself. This is easy to do and it works."

Well. Doesn't work for me, and I've restarted Tomcat 5.5 so much I can
do it blindfolded soon. Yes, I've installed commons-loggin.jar and
log4-1.2.9.jar in WEB-INF/lib. All logs are still written to
stderr_xxxx.log and no formatting is gathered from the properties file.
I wonder...

Yeah. Putting the log4j.properties file in WEB-INF/classes only works if
you've only got ONE logj4.properties file and ONE webapp.

I put the libraries and the properties file in tomcat's common/lib and
common/classes directories respectively, and took them out of the webapps'
directories completely. Loggers which are declared in the properties file
like this:

log4j.logger.VoipDev = TRACE, VD

get instantiated in the webapp code like this:

private static Log log = LogFactory.getLog("VoipDev");

 

[Babu Kalakrishnan]

Yeah. Putting the log4j.properties file in WEB-INF/classes only works if
you've only got ONE logj4.properties file and ONE webapp.

That's clearly incorrect. As a matter of fact the recommended way
(putting it in the WEB-INF/classes directory of the webapp) is the only
one that will allow individual apps to configure its own logging
strategy independently - if everything works as advertised. The
classloaders that load the Commons-Logging and Log4J libraries are
independent for each application and so should not share any state
between them - theoretically.

I'm not saying that it works perfectly that way though. I've seen this
exact problem of logs ending up in catalina.out (or whatever log file
you've configured for Tomcats stdout/stderr) mostly with Turbine
applications, and have never been able to track down the exact cause. My
guess is that it's most likely to be some sort of mess-up in Tomcat's
classloaders or the way Commons logging is initialized by the webapp.
(Or a mixture of the two).

I put the libraries and the properties file in tomcat's common/lib and
common/classes directories respectively, and took them out of the webapps'
directories completely. Loggers which are declared in the properties file
like this:

log4j.logger.VoipDev = TRACE, VD

get instantiated in the webapp code like this:

private static Log log = LogFactory.getLog("VoipDev");

Now imagine a case when you have multiple struts applications running on
Tomcat, and you want to enable DEBUG logging for the Struts library
classes on one app which is not behaving right. You'll find your logs
flooded with "DEBUG" logs of all other apps - with no easy way (Not sure
there's a "difficult" way either) to distinguish which log line belongs
to which application.


BK

 

[Ingo R. Homann]

Hi Ole,

I have encountered problems with java finding the correct
log4j.properties as well.

I solved all problems with not using a log4j.properties-file, but to
configure the Loggers programmatically.

Maybe, this is an option for you, too.

Ciao,
Ingo

 

[Peter Davies]

That's clearly incorrect. As a matter of fact the recommended way
(putting it in the WEB-INF/classes directory of the webapp) is the only
one that will allow individual apps to configure its own logging
strategy independently - if everything works as advertised. The
classloaders that load the Commons-Logging and Log4J libraries are
independent for each application and so should not share any state
between them - theoretically.

I know it's *supposed* to be incorrect, but after struggling blindly with
the accepted procedure for a good week, it seemed best to stop RTFM-ing
and experiment for a change.

I'm not saying that it works perfectly that way though. I've seen this
exact problem of logs ending up in catalina.out (or whatever log file
you've configured for Tomcats stdout/stderr) mostly with Turbine
applications, and have never been able to track down the exact cause. My
guess is that it's most likely to be some sort of mess-up in Tomcat's
classloaders or the way Commons logging is initialized by the webapp.
(Or a mixture of the two).



Now imagine a case when you have multiple struts applications running on
Tomcat, and you want to enable DEBUG logging for the Struts library
classes on one app which is not behaving right. You'll find your logs
flooded with "DEBUG" logs of all other apps - with no easy way (Not sure
there's a "difficult" way either) to distinguish which log line belongs
to which application.

No. Catalina.out gets flooded with everybody's logs, because it is the
"rootLogger". Each other webapp gets its own special file to log to, and
it does.

To be more precise: I have three webapps running on one system, with their
loggers defined like so:

log4j.rootLogger=INFO, R

log4j.logger.VoipAdmin = INFO, AD
log4j.logger.VoipAuth = INFO, VP
log4j.logger.VoipDev = TRACE, VD

The files they log to are defined like this:

log4j.appender.AD.File=/var/tomcat/logs/voipadmin.log
log4j.appender.VP.File=/var/tomcat/logs/voip.log
log4j.appender.VD.File=/var/tomcat/logs/voipdev.log

I don't define a file for 'R', so that just logs to catalina.out. I
instantiate a DailyRollingFileAppender for 'R', so catalina.out gets
itself rotated every day too!

My system uses Tomcat 5.0.28 and log4j 1.2.11.

 

[Ole Christian Langfjaeran]

Peter Davies wrote:

I'm not saying that it works perfectly that way though. I've seen this exact
problem of logs ending up in catalina.out (or whatever log file you've
configured for Tomcats stdout/stderr) mostly with Turbine applications, and
have never been able to track down the exact cause. My guess is that it's
most likely to be some sort of mess-up in Tomcat's classloaders or the way
Commons logging is initialized by the webapp. (Or a mixture of the two).

Found the problem at last(and fortunately my scalp doesn't look like a
rabid dog). As you guessed the problem was in the way commons logging was
initialized. Seems I was using an old commons-logging.jar which didn't
load log4j.properties. Using a newer one fixed the problem right away.

Now imagine a case when you have multiple struts applications running on
Tomcat, and you want to enable DEBUG logging for the Struts library classes
on one app which is not behaving right. You'll find your logs flooded with
"DEBUG" logs of all other apps - with no easy way (Not sure there's a
"difficult" way either) to distinguish which log line belongs to which
application.

I agree with BK. Using the logger as PT suggests would result in a log not
containing references to the classes responsible for the logging. And with
a big application with many classes that could prove a very difficult task
distinguishing the various logging.

All the same, thank you all for the help!