Servlet not reading log4j.properties

Discussion in 'Java' started by Ole Christian Langfjaeran, Oct 19, 2005.

  1. 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.
     
    Ole Christian Langfjaeran, Oct 19, 2005
    #1
    1. Advertising

  2. Ole Christian Langfjaeran

    Peter Davies Guest

    On Wed, 19 Oct 2005 14:01:53 +0200, Ole Christian Langfjaeran wrote:

    > 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");



    --
    Peter Davies
     
    Peter Davies, Oct 19, 2005
    #2
    1. Advertising

  3. Peter Davies wrote:
    > On Wed, 19 Oct 2005 14:01:53 +0200, Ole Christian Langfjaeran wrote:
    >
    >
    >>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.
    >


    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
     
    Babu Kalakrishnan, Oct 19, 2005
    #3
  4. 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
     
    Ingo R. Homann, Oct 20, 2005
    #4
  5. Ole Christian Langfjaeran

    Peter Davies Guest

    On Wed, 19 Oct 2005 22:57:09 +0530, Babu Kalakrishnan wrote:

    > Peter Davies wrote:
    >> On Wed, 19 Oct 2005 14:01:53 +0200, Ole Christian Langfjaeran wrote:
    >>
    >>
    >>>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.
    >>

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


    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.

    --
    Peter Davies
     
    Peter Davies, Oct 20, 2005
    #5
  6. On Wed, 19 Oct 2005, Babu Kalakrishnan wrote:

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

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


    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!
     
    Ole Christian Langfjaeran, Oct 20, 2005
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Alexandra Stehman

    eclipse, junit, log4j, & finding log4j.xml

    Alexandra Stehman, Jan 19, 2004, in forum: Java
    Replies:
    0
    Views:
    5,851
    Alexandra Stehman
    Jan 19, 2004
  2. circuit_breaker
    Replies:
    2
    Views:
    2,081
    Jack Jia
    Apr 4, 2004
  3. Alex Hunsley
    Replies:
    2
    Views:
    13,075
    =?ISO-8859-15?Q?Fr=E9d=E9ric_G=E9din?=
    May 28, 2004
  4. Rodolfo
    Replies:
    0
    Views:
    983
    Rodolfo
    Jul 12, 2004
  5. Gianni Galore
    Replies:
    0
    Views:
    1,316
    Gianni Galore
    Sep 8, 2010
Loading...

Share This Page