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

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.

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)