logback mit EJB3.1
Ich bin mit logback/slf4j zu handhaben Protokollierung in meiner Anwendung. Alles lief perfekt, bis ich begann mit EJBs. Einmal habe ich ein stateless EJB, meine app, die logger gestartet ignoriert meine logback.xml und nicht mehr mit meinem appenders. Ich wechselte zu einer programmatischen logger-Konfiguration, um zu sehen, was falsch war und jetzt bin ich immer die folgende Fehlermeldung, wenn ich versuche, mit meinem logger innerhalb des EJB:
org.slf4j.impl.JDK14LoggerFactory cannot be cast to ch.qos.logback.classic.LoggerContext
sich aus der Zeile:
LoggerContext lc = (LoggerContext) LoggerFactory.getILoggerFactory();
Gibt es da eine spezielle Konfiguration notwendig, um logback arbeiten mit EJBs? Wenn es darauf ankommt, ich bin die Bereitstellung auf glassfish v3.
Thivent: ja, ich glaube schon, ich bin mit slf4j statischen loggerfactory Methode und logback als meine Implementierung. Die seltsame Sache ist das genaue code war perfekt funktioniert, bevor ich begann, EJBs
Ja, das ist komisch. Aber vielleicht ist das problem versteckt war, so weit und hinzufügen eines EJB ausgelöst einigen besonderen zum laden von Klassen Sachen, die es offenbart.
Die EJB-Module zu ziehen in eine slf4j "upstream" in der classloader für einige Grund, und das slf4j konfiguriert dann in seinem Kontext. Dann ist das, was wird verwendet, wenn Ihr code braucht seinen logger.
Können Sie reproduzieren dieses Verhaltens mit 3.0.1?
InformationsquelleAutor kgrad | 2010-03-10
Du musst angemeldet sein, um einen Kommentar abzugeben.
Diese sieht sehr nah an der beschriebenen Problematik in dieser thread und ich vermute, einen ähnlichen laden von Klassen Problem. Wegen der Art, wie logback Lasten
logback.xml
(genauer gesagt die Art und Weise es ruft eineClassLoader
zu tun), es kann einen Fehler bei der Kommissionierung bis seine Konfigurationsdatei und fallen zurück auf eine Standard -BasicConfiguration
.Nicht sicher, wie Sie Sie Verpacken Sie Ihre code, aber der workaround besteht darin, die
logback.xml
im OHR lib. Wenn Sie nicht über ein OHR, Verpackung, versuchen zu identifizieren, der class-loader verwendet, um zu sehen, wohin dielogback.xml
- Datei.Am Ende, könnte dies ein problem in logback. Nicht überprüfen, Ihre issue-tracker aber.
Update: Wenn Sie einen Krieg Verpackung, versuchen, konfigurieren Sie GlassFish verwenden, Erstens das Kind classloadern, bevor Sie zu delegieren. In dersun-web.xml
:Update: ich habe einen kleinen test auf meiner Seite und... ich kann Ihr problem reproduzieren. Ich habe ein Projekt für eine Java-EE-6-webapp, welche die folgende Struktur hat:
Meine pom.xml sieht aus wie:
Den code für
SimpleEJB.java
ist:Den code für
SimpleServlet.java
ist:Den code für
index.jsp
ist:Und meine
logback.xml
aussieht:Meine
logback.xml
bekommt propertly geladen und ich bekomme folgende trace (entnommen aus meinem log-Datei), dass beim Aufruf der servlet:Tat ich das auch versuchen mit der EJB-verpackt in eine eigene JAR und eingesetzt in
WEB-INF/lib
und das gleiche Ergebnis, es funktioniert einfach. Können Sie vor Ort alle erkennbaren Unterschied? Vielleicht laden Sie eine vereinfachte version der app (wird sehr wahrscheinlich erforderlich, für den bug-Bericht BTW).Ich bin mit GlassFish v3 unter Eclipse 3.5 (mit GlassFish v3 plugin).
Oh ich sehe. Ich Frage mich wirklich, wie GFv3 Griffe EJBs (d.h. die Belastungen) verpackt in einem KRIEG. Leider nicht überprüfen.
Wenn Sie interessiert sind, meine Abhängigkeiten sind: logback-core-0.9.18, logback-classic 0.9.18 und slf4j-api-1.5.11
Vielen Dank für die Arbeit, die Sie tun, ich werde vereinfachen, meine app und laden Sie Sie morgen, wo soll ich es posten? Als eine weitere Antwort in diesem thread? Ich bin eigentlich ruft mein logger in einen interceptor, vielleicht ist das ein Beitrag zu dem Fehler, ich weiß nicht, warum ich nicht glaube, dass der vor...
Gepostet werden die relevanten code, einige der Formatierung ist ein bisschen off, aber ich wusste nicht wie es zu lösen ist.
InformationsquelleAutor Pascal Thivent
Den
org.slf4j.impl.JDK14LoggerFactory cannot be cast to ch.qos.logback.classic.LoggerContext
Ausnahme zeigt, dass SLF4J ist nicht gebunden an die logback-classic aber zu slf4j-jdk14. In kurzen, logback-code ist nicht zu tadeln, weil es nicht ausgeübt wird noch genannt.Sieht es aus wie GFv3 ist der Export slf4j-jdk14.jar in Ihrer Anwendung und damit überschreiben Sie Ihre Wahl des logging-back-end, logback in diesem Fall. Dies ist eines jener Szenarien, in denen der app-server versehentlich erlegt seine Entscheidungen auf die Benutzer.
Wenn ja GFv3 legt Sie die SLF4J-Bindung an die end-user, dann ist das eine GFv3 Problem, das muss gelöst werden, indem GFv3 Entwickler. Ich könnte falsch sein, aber ich denke, dass Sie davon ausgehen, dass die end-Benutzer nicht wollen, dass andere logging-Funktionalität über das hinaus, was vorgesehen ist, die von java.util.Protokollierung und nur bundle-slf4j-jdk14 in GFv3. Die Bedürfnisse der Nutzer, Sie zu Kontaktieren und sich beschweren, dass Ihre Annahme falsch ist. Es ist auch möglich, dass Sie sich dieses Themas bewusst sind und bereits ein workaround...
Gibt es eine Möglichkeit, ich kann dies außer Kraft setzen? Oder muss ich mein logging-Strategie?
Sie brauchen, um GFv3 Leute, die in dieser oder zumindest bewusst zu machen, dass die Bündelung slf4j-jdk14 in GFv3 hat seine Nachteile.
InformationsquelleAutor Ceki
Grundsätzlich das problem ist, dass der application server
verwendetbietet slf4j UND dass Ihre versuche zu benutzen geht es auf dem application server slf4j-Bindung statt, die Sie selber will.Können Sie nicht nur verwenden Sie die slf4j-Bindung in Glassfish?
Bearbeitet beantworten. Aber ist ist eine faszinierende problem - anscheinend ist es so schwer zu bekommen genau das richtige, dass auch 10 Jahre daran zu arbeiten, noch nicht gelöst. Java-Commons Logging verwenden classloader-Magie, slf4j verwendet die normalen classloader-Bindungen.
wenn Sie downvote, dann bitte es rückgängig machen, wenn Sie sich entscheiden, um Ihren Kommentar zu löschen...
InformationsquelleAutor Thorbjørn Ravn Andersen