Servlet not reading log4j.properties

Thread view:

Ole Christian Langfjaeran - 19 Oct 2005 13:01 GMT

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.

Reply to this Message

Peter Davies - 19 Oct 2005 16:24 GMT

> Closing in on a serious hearloss soon with this problem. According to
> http://logging.apache.org/log4j/docs/manual.html : "... you should place
[quoted text clipped - 7 lines]
> 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");

Signature

Peter Davies

Reply to this Message

Babu Kalakrishnan - 19 Oct 2005 18:25 GMT

>>Closing in on a serious hearloss soon with this problem. According to
>>http://logging.apache.org/log4j/docs/manual.html : "... you should place
[quoted text clipped - 10 lines]
> 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'
[quoted text clipped - 6 lines]
>
> 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

Reply to this Message

Peter Davies - 20 Oct 2005 09:09 GMT

>>>Closing in on a serious hearloss soon with this problem. According to
>>>http://logging.apache.org/log4j/docs/manual.html : "... you should place
[quoted text clipped - 18 lines]
> 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
[quoted text clipped - 21 lines]
> 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.

Signature

Peter Davies

Reply to this Message

Ole Christian Langfjaeran - 20 Oct 2005 09:14 GMT

> 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.

>> 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'
[quoted text clipped - 13 lines]
> "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!

Reply to this Message

Ingo R. Homann - 20 Oct 2005 08:02 GMT

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

Reply to this Message

Servlet not reading log4j.properties

Free Magazines