2016-06-13 12 views
0

Wir haben SLF4J Logger API erweitert und AppLogger Schnittstelle erstellt. Wir müssen dies für bestimmte Bedürfnisse tun, die ich hier nicht offen legen kann. Jetzt möchten wir diesen erweiterten Logger mit LogBack Framework verwenden. Ich bin nicht in der Lage, einen Mechanismus zu finden, wie es funktioniert. Direkte Verwendung wirft ClassCastException (das ist offensichtlich, da es eine Klasse mit Name Logger erwartet und AppLogger abruft).Verwendung von erweiterten SLF4J mit Logback

Ich bin in der Lage, diese erweiterte Schnittstelle arbeiten mit Log4J 1.x und Log4J 2.x durch Schreiben einer Bridge-Implementierung und bietet benutzerdefinierte StaticBinder Klassen. Für LogBack ist diese Bridge-Klasse (StaticBinder) Teil der JAR-Datei logback-classic, daher bin ich mir nicht sicher, wie ich meinen eigenen Binder schreiben und LogBack überbrücken soll.

Die AppLogger Schnittstelle wie folgt aussieht:

public interface AppLogger extends org.slf4j.Logger { 
    public void myOwnMethod(String message, Object... args); 
} 

freuen, wenn jemand eine Idee geben.

+0

@Raedwald, Ich habe meine Frage bearbeitet, um die erweiterte Schnittstelle hinzuzufügen. Ich muss einige weitere anwendungsspezifische Protokollierungsmethoden hinzufügen. Ich verstehe auch, dass Sie LogBack erweitern möchten. Ich weiß, dass ich eine Implementierung bereitstellen muss, die äquivalent zu "ch.qos.logback.classic.Logger" ist, was meinen 'AppLogger' erweitern würde, aber in diesem Fall muss ich Code für alle Klassen bereitstellen, die in' logback-classic' vorhanden sind KRUG. Ich kann mir keine andere Idee vorstellen. Bitte schlagen Sie vor, wenn Sie einen anderen Gedanken haben. – Niranjan

+1

Es ist schwer für mich, sich vorzustellen, warum Sie möglicherweise die Logger-Kernschnittstelle erweitern müssen, um etwas zu tun, was nicht über Markierer oder MDC oder einen anderen der eingebauten Mechanismen möglich ist. Sie sind wahrscheinlich besser dran, wenn Sie die Logger-Oberfläche nicht anpassen, sondern nur Ihre eigene Methode bereitstellen, die alle Ihre Klassen statisch importiert. –

Antwort

2

Bis zur Version 1.7.15 war der SLF4J-Bindemechanismus sehr, sehr, sehr einfach. Nach der Version 1.7.15 wurde der Mechanismus mit der Einführung der Ereigniswiederholung etwas komplizierter, aber die Kernbindungsidee bleibt einfach. Für diejenigen, die nicht gestört werden können, kann jede Unterstützung für die Ereigniswiedergabe sicher weggelassen werden.

Beispiele für slf4j-Bindungen finden Sie im Code in den Modulen slf4j-nop oder slf4j-simple.

jedoch von dem, was ich sammeln, wünschen Ihnen eine erweiterte Logger-API verwenden, in dem Fall, dass Sie in LoggerWrapper, XLogger und XLoggerFactory Klassen im slf4j-ext-Modul aussehen sollte. Sie sollten das gleiche Verfahren für Ihre AppLogger-Schnittstelle problemlos emulieren können.