J'ai un curieux problème. J'avais cette Java qui a été précédemment déployée dans Tomcat et qui a heureusement utilisé logback classic comme implémentation slf4j. Maintenant, lorsque nous avons essayé de déployer la même application sur un serveur jboss 7.1.final, elle ne fonctionne pas. même déployer le maoning d'application sur Java.lang.ClassCastException: org.slf4j.impl.Slf4jLoggerFactory cannot be cast to ch.qos.logback.classic.LoggerContext
Ceci est la ligne de code incriminée
final LoggerContext lc = (LoggerContext) LoggerFactory.getILoggerFactory();
La classe qui a le sien est injectée par ressort et qui échoue - par conséquent, l'application entière ne peut pas être déployée. Quelqu'un a une solution à cela? Merci d'avance
Après avoir consulté ce site et d'autres forums, j'ai réalisé que Jboss 7 est livré avec sa propre implémentation slf4j et implémente la même interface ILoggerFactory que LoggerContext dans Logback. Notre application a essayé d'obtenir une instance de la même chose mais le serveur d'application impose sa propre implémentation slf4j.
J'ai essayé de modifier le module.xml dans jboss\modules\org\slf4j\impl\main et l'ai pointé vers des pots de déconnexion.
<resources>
<resource-root path="logback-classic-0.9.28.jar"/>
<resource-root path="logback-core-0.9.28.jar"/>
</resources>
Maintenant, quand je démarre l'application, je reçois une erreur grave
Exception starting filter WicketFilter: Java.lang.ClassCastException: ch.qos.logback.classic.LoggerContext cannot be cast to ch.qos.logback.classic.LoggerContext
Je suis à bout de souffle. Des experts jboss et logback peuvent-ils vous aider? Merci d'avance
Vous devez exclure la version serveurs de slf4j de votre déploiement. Créer un jboss-deployment-structure.xml
fichier et placez-le dans votre WARS META-INF
ou WEB-INF
répertoire.
Le contenu du fichier devrait ressembler à ceci:
<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>
Si vous utilisez les ponts pour jul ou jcl dans votre application, vous devez également les exclure:
<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" />
Il existe une approche alternative:
Il suffit de désactiver complètement la journalisation JBoss et de compter sur les dépendances de votre guerre . Modifiez votre jboss-deployment-structure.xml
comme suit:
<?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>
Une fois que vous déployez votre application, bootstrap logging (boot.log) continue de fonctionner également server.log affichera la journalisation du déploiement. Mais toute votre application est connectée via votre (dans cet exemple) slf4j + logback in votre guerre.
Notez que vous ne devriez pas avoir besoin d'exécuter JBoss avec -Dorg.jboss.logging.provider=slf4j
, si vous le spécifiez, vous devrez fournir des modules JBoss (généralement slf4j-api, logback-classic et logback-core), mais cela ne vaut pas la peine, car la journalisation JBoss n'est désormais utilisée que pour bootstrap (boot.log) et pour les informations de déploiement (server.log).
Références:
http://tinyapps.blogspot.com/2013/01/getting-logback-and-slf4j-to-work-in.html
https://stackoverflow.com/a/19695680/258734