Log4jConfigListener problem

[scottr]

Hi all,

I have configured a web application to use log4j logging using the Log4jConfigListener, running in Tomcat 5.0.25. All of my logging calls use commons-logging. But for some reason the system, when running, chooses the jdk1.4 logger rather than the log4j logger.

The log files I have configured in log4j.properties actually do get created by Spring, but for some reason commons-logging doesn't use the Spring configured logging.


Here is a copy of my web.xml file for reference:

<web-app>
    <display-name>Esmart web booking</display-name>

    <!--
      - Key of the system property that should specify the root directory of this
      - web app. Applied by WebAppRootListener or Log4jConfigListener.
      -->
    <context-param>
        <param-name>webAppRootKey</param-name>
        <param-value>esmart.root</param-value>
    </context-param>

    <!--
      - Location of the Log4J config file, for initialization and refresh checks.
      - Applied by Log4jConfigListener.
      -->
    <context-param>
        <param-name>log4jConfigLocation</param-name>
        <param-value>/WEB-INF/conf/log4j.properties</param-value>
    </context-param>

    <!--
      - Specifies to system where to find Spring bean definition files.
      - Applied by ContextLoaderListener.
      -->
    <context-param>
        <param-name>contextConfigLocation</param-name>
        <param-value>/WEB-INF/conf/spring-beans.xml /WEB-INF/conf/services.xml</param-value>
        <description>Location of Spring application context configuration files</description>
    </context-param>

    <!--
      - Configures Log4J for this web app.
      - As this context specifies a context-param "log4jConfigLocation", its file path
      - is used to load the Log4J configuration, including periodic refresh checks.
      -
      - Would fall back to default Log4J initialization &#40;non-refreshing&#41; if no special
      - context-params are given.
      -
      - Exports a "web app root key", i.e. a system property that specifies the root
      - directory of this web app, for usage in log file paths.
      - This web app specifies "esmart.root" &#40;see log4j.properties file&#41;.
      -->
    <listener>
        <listener-class>org.springframework.web.util.Log4jConfigListener</listener-class>
    </listener>

    <!--
      - Listener that creates a Spring ApplicationContext upon startup, populated by
      - the beans defined in the contextConfigLocation param above.
      -->
    <listener>
        <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
    </listener>


    <!--
      - Specifies a filter that opens and binds a Hibernate session to the current
      - thread for the lifetime of the request/response.
      -->
    <filter>
        <filter-name>Hibernate Filter</filter-name>
        <filter-class>org.springframework.orm.hibernate.support.OpenSessionInViewFilter</filter-class>
        <init-param>
            <param-name>sessionFactoryBeanName</param-name>
            <param-value>sessionFactory</param-value>
        </init-param>
    </filter>
    <filter-mapping>
        <filter-name>Hibernate Filter</filter-name>
        <url-pattern>/*</url-pattern>
    </filter-mapping>


    <!--
      - Specifies a filter that redirects incoming requests to the 
      - main Tapestry application servlet &#40;ie. esmart application servlet&#41;
      -->
    <filter>
        <filter-name>redirect</filter-name>
        <filter-class>org.apache.tapestry.RedirectFilter</filter-class>
    </filter>
    <filter-mapping>
        <filter-name>redirect</filter-name>
        <url-pattern>/</url-pattern>
    </filter-mapping>


    <servlet>
        <servlet-name>esmart</servlet-name>
        <servlet-class>org.apache.tapestry.ApplicationServlet</servlet-class>
        <load-on-startup>1</load-on-startup>
    </servlet>
    <servlet-mapping>
        <servlet-name>esmart</servlet-name>
        <url-pattern>/app</url-pattern>
    </servlet-mapping>
</web-app>

If you have any thoughts on this or similar experiences I'd like to hear them.

regards,
Scott

[ojolly]

Your configuration does look ok. I did several webapp with a similar web.xml conf (just with less filters usually). I always had log4j choosen when it was in the classpath.
Could you check your catalina.out and the normal log from tomcat localhost-* in ./logs/ to see if there's any explanation on the selection of jdk1.4 instead of log4j ?

Olivier

[scottr]

Your configuration does look ok. I did several webapp with a similar web.xml conf (just with less filters usually). I always had log4j choosen when it was in the classpath.
Could you check your catalina.out and the normal log from tomcat localhost-* in ./logs/ to see if there's any explanation on the selection of jdk1.4 instead of log4j ?

Olivier

Hi Olivier,

Yeah, I did check the output of the tomcat logs. There are no tomcat specific messages about logging of any sort - the only messages are about four lines from Spring as the listener starts up and initialises the log4j. Nothing untoward there.

Its a mystery to me. I have had classpath problems in the past using commons-logging with older versions of Tomcat, but those appeared to have been fixed by version 5. I don't know if converting to log4j exclusively would help, although I don't fancy the prospect of converting all the references in code.

Scott

[scottr]

Hi All,

I managed to solve this problem. I was using commons-logging-1.0.2, whereas I should have been using commons-logging-1.0.3 (at least, when using log4j > 1.2).

Another black mark in the commons-logging book in my experience.

On the topic of the log4j support in Spring, it would be nice to see similar support for the jdk1.4 logging. Are there any plans to produce similar support classes for that api? Having looked at the Log4jWebConfigurer etc, it looks as if it would be 80% cut-and-paste.

Scott