SpringMVC e log4j: impossibile inizializzare log4j prima di Spring

[fbcyborg]

Salve a tutti,

sto cercando di sistemare una Web Application basata su SpringMVC, per quanto riguarda il logging. L'obiettivo è quello di far loggare la Web Application su file in path specificato nel file di configurazione stesso.

Premesso che ho creato una nuova webapp da zero e che con questa riesco a far loggare su filesystem al path specificato esterno alla webapp, non riesco a capire perché non funzioni sull'altra.

Utilizzo il seguente sistema in web.xml:

    <context-param>
        <param-name>log4jConfigLocation</param-name>
        <param-value>file://${myapp.properties}/log4j.xml</param-value>
    </context-param>

    <listener>
        <listener-class>org.springframework.web.util.Log4jConfigListener</listener-class>
    </listener>

Chiaramente il sistema del placeholder funziona, e anche sostituendolo con il path vero non cambia nulla.

Il problema è che la webapp continua a loggarmi in console, a livello DEBUG, ed è come se il Log4jConfigListener venisse ignorato. Inoltre non so dove log4j vada a prendere i settaggi di default e loggare in console.

Ne ho provate di tutti i colori: Servlet di inizializzazione, Filtri, bean Spring, controllato librerie. Non ho più idea di cosa possa impedire questa webapp dal loggare come e dove dico io.

Qualcuno potrebbe aiutarmi a capire come posso obbligare questa webapp a caricare il logger prima dello spring context initialization?

Grazie


EDIT: una cosa che ho notato è la seguente. Sto utilizzando questa libreria:

      <dependency>
          <groupId>javax.servlet</groupId>
          <artifactId>servlet-api</artifactId>
          <version>2.5</version>
          <scope>provided</scope>
      </dependency>

Non vorrei che sia la causa di tutto ciò. Nell'esempio funzionante utilizzo Tomcat 7.0.53 con la runtime 1.7, mentre nel caso dove non funziona la runtime è la 1.6. Su Tomcat 7.0.53, è presente un servlet-api.jar con java specification 3.0.

[fbcyborg]

Ho finalmente capito qual'è la causa del problema.
La webapp, veniva deployata in un contesto in cui fra le shared libraries c'è logback-classic. In questo modo, si creava un conflitto con slf4j e loggava in console.