Frage

Ich habe ein neugieriges Problem. Ich hatte diese Java-Anwendung, die zuvor in Tomcat eingesetzt wurde, und verwendete Logback Classic als SLF4J-Implementierung. Wenn wir jetzt versucht haben, dieselbe App in einem JBoss 7.1.final-Server bereitzustellen java.lang.ClassCastException: org.slf4j.impl.Slf4jLoggerFactory cannot be cast to ch.qos.logback.classic.LoggerContext. Dies ist die beleidigende Codezeile generasacodicetagpre.

Die Klasse, die seinen Frühling injiziert hat, und das ist fehlend - daher kann die gesamte Anwendung nicht bereitgestellt werden. Hat jemand eine Lösung dafür? Vielen Dank im Voraus

Nachdem ich in dieser Site in dieser Site überschaut hatte Unsere Anwendung versuchte, eine Instanz von dasselbe zu erhalten, aber der App-Server stellt die eigene SLF4J-Implementierung auf.

Ich habe versucht, das Modul.xml in JBoss \ Modules \ Org \ SLF4J \ Impl \ Main zu ändern, und darauf hingewiesen, dass sie die JARs anmelden. generasacodicetagpre.

Jetzt, wenn ich die Anwendung starte, bekomme ich einen ernsthaften Fehler

Exception starting filter WicketFilter: java.lang.ClassCastException: ch.qos.logback.classic.LoggerContext cannot be cast to ch.qos.logback.classic.LoggerContext

Ich bin an meinem Wits enden. Jedes JBoss und Logback-Experten können helfen? Vielen Dank im Voraus

War es hilfreich?

Lösung

You need to exclude the servers version of slf4j from your deployment. Create a jboss-deployment-structure.xml file and place it in either your WARS META-INF or WEB-INF directory.

The contents of the file should look like this:

<jboss-deployment-structure>
    <deployment>
        <!-- Exclusions allow you to prevent the server from automatically adding some dependencies     -->
        <exclusions>
            <module name="org.slf4j" />
            <module name="org.slf4j.impl" />
        </exclusions>
    </deployment>
</jboss-deployment-structure>

Andere Tipps

If you are using the bridges for jul or jcl in your app, you should exclude them too:

        <module name="org.slf4j" />
        <module name="org.slf4j.jcl-over-slf4j" />
        <module name="org.slf4j.impl" />
        <module name="org.jboss.logging.jul-to-slf4j-stub" />

There is alternative approach:

  • you got logging configured in your war
  • you got all dependencies in your war
  • you don't configure anything in JBoss server directory, not even additional JBoss modules

Just disable JBoss logging completely and rely on the dependencies in your war. Edit your jboss-deployment-structure.xml as follows:

<?xml version="1.0" encoding="UTF-8"?>
<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.0">
    <deployment>
        <exclusions>
            <module name="org.apache.commons.logging" />
            <module name="org.apache.log4j" />
            <module name="org.jboss.logging" />
            <module name="org.jboss.logging.jul-to-slf4j-stub" />
            <module name="org.jboss.logmanager" />
            <module name="org.jboss.logmanager.log4j" />
            <module name="org.slf4j" />
            <module name="org.slf4j.impl" />
            <module name="org.slf4j.jcl-over-slf4j" />
        </exclusions>
    </deployment>
</jboss-deployment-structure>

Once you deploy your app, bootstrap logging (boot.log) keeps working also server.log will show deployment logging. But all your application is logged through your (in this example) slf4j+logback in your war.

Note that you should not need to run JBoss with -Dorg.jboss.logging.provider=slf4j, if you specify this, you will need to provide JBoss modules (typically slf4j-api, logback-classic and logback-core), but it is not worth the effort, as JBoss logging is now used only for bootstrap (boot.log) and for deployment info (server.log).

References:
http://tinyapps.blogspot.com/2013/01/getting-logback-and-slf4j-to-work-in.html
https://stackoverflow.com/a/19695680/2587343

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top