Changing application context path leads to using different (unknown) logging configuration

Question

Setup:

• Tomcat 6.0.16
• Struts 2.1.6
• Apache Commons Logging 1.0.4
• Log4J 1.2.17

What I did:

Change in server.xml:

<Context path="/" .../></Context>

to

<Context path="/shop" .../></Context>

The issues:

Everything in the application is working fine (on the first glance). All links are correct and working etc.

Now I discovered that the Loggers using Commons Logging (with Log4J) (usually the Loggers in Spring, Struts and OGNL) are using a different logger configuration than the default used before. Loggers using Log4J directly in the application are working fine with this configuration.

For debugging purpose I have a JSP listing all the loggers with:

Logger.getRootLogger().getLoggerRepository( ).getCurrentLoggers()

But the "commons logging logger" are not listed anymore, although I could verify that they exist if I debug the code.

The question:

• How do I find the other configuration/root logger?
• Do I have to change anything in the struts configuration (or somewhere else) in relation to the context path change?
• Any ideas what the issue might be here?

Edit: I'm getting closer:

The platform I am using is loading a minimal logging at start up. Before changing the context the advanced logging was loaded right afterwards and everything was fine. For some reason the listener of the web.xml (Spring initialization, etc.) is now running before the advanced logging is loaded. These classes are using the apache commons logging api and get loggers assigned basing on the simple root logger. Right afterwards the root logger is replace by the platform but the commons loggers are not updated with the new configuration.

New question: As I stated below, changing anything in the platform is no option. So why did the listener run earlier when I change the context and how can I prevent this.

Answer 1

The logging creates a dependency between multiple tomcat web application and due this fact requires a specific order of loading this modules. Renaming the context to "/shop" leads to an other order as StandardContext.filterDefs is a simple HashMap and does not preserve the order of the server.xml.

I could fix my issues in running the required steps in a listener.

web.xml

<listener>
     <listener-class>com.[...].InitListener</listener-class>
</listener>

InitListener.java

package com.[...];

public class InitListener
{
    static
    {
        // init Log4J, etc.
    }
}

{code}

(Btw. Listener order should be identical to the web.xml)

Answer 2

For the sake of the moment Apache Tomcat uses JDK logging. If you didn't place commons-logging.properties file to your source dir the default logger using commons logging will be log4j. Anyway the Tomcat will not use that logging because it needs a special configuration to tell it to use log4j.

The root logger is what you use in the log4j configuration. For example

log4j.rootLogger=ERROR,Console  

Changing context path is nothing related to the logging used by application.

I didn't see any issue with logging rather that in recent releases regarding implementation priority.