Gemäß der c3p0-Dokumentation können Sie manuell angeben, wohin Protokolle geleitet werden sollen, sei es durch JDK 1.4-Protokollierung , Log4j oder über System.out. Ich führe SLF4J aus, also habe ich org.slf4j.jul-to-slf4j und% SLF4JBridgeHandler.install() in meine Anwendung eingefügt, um zu erzwingen, dass alle Java-Util-Logging SLF4J durchlaufen. Außerdem habe ich die folgende Eigenschaft in meine c3p0.properties -Datei eingefügt:
Dies wird laut Dokumentation dazu führen, dass c3p0 bei der Protokollierung von JDK 1.4 protokolliert wird, was wiederum die Dinge in SLF4J protokolliert. Das funktioniert etwas, aber ich sehe immer noch, dass einige Logs System.err :
Beispiel 1:
%Vor% Zeilen 1 und 6 oben werden in SLF4J geschrieben, die anderen werden in System.err geschrieben.
Beispiel 2:
%Vor% Die ersten beiden obigen Zeilen werden in System.err protokolliert, was überhaupt keinen Sinn ergibt, da sie sich auch wie beabsichtigt an SLF4J anmeldet.
Gibt es eine Möglichkeit für mich, die Protokollierung in System.err von c3p0 zu deaktivieren?
Das Hinzufügen der folgenden Abhängigkeit kümmert sich um einige der Probleme, jedoch nicht alle.
%Vor%Außerdem müssen Sie die irritierende Logik in dieser Datei umgehen:
Durch Angabe dieser leeren Klasse:
%Vor%Einige Diskussionen zu diesem Thema finden Sie hier:
Ich plane, eine einzige Klassenabhängigkeit zu erstellen, die für diesen Zweck von log4j-over-slf4j abhängig ist, jedoch so wie sie ist in einem Projekt funktioniert. Ich kann jetzt von slf4j-nop zu slf4j-simple zu Logback wechseln und bekomme die erwarteten Ergebnisse, sowohl von meinem eigenen Code, als auch von Hibernate / C3P0.
Seit die akzeptierte Antwort geschrieben wurde (vor fast drei Jahren), wurde in Version 0.2.5 des mchange-commons-java Artefakts direkte Unterstützung für slf4j Logging in jedes Backend hinzugefügt, was die c3p0-Dokumentation verwendet .
zB: ' com.mchange.v2.log.MLog = com.mchange.v2.log.slf4j.Slf4jMLog '
Allerdings ... Die letzte stabile Version in Maven Central (0.9.2.1) von c3p0 verwendet diese Version nicht. Sie müssten auf mindestens 0.9.5-pre2 upgraden, um diese Konfiguration zu verwenden. Die neueste unveröffentlichte Version ist 0.9.5-pre7
Dies würde vermeiden, entweder:
Das tun wir, um in slf4j und logback zu routen. In einer Anwendung müssen wir jedoch immer noch die log4j-Bridge verwenden, bis eine neue Version von hibernate-c3p0 von hibernate veröffentlicht wird, die die c3p0-Version aktualisiert.
Ich vermute, dass dies eines der Probleme ist, auf die FredCookes Antwort verweist ... aber es könnte zwei Probleme verwirren. Hibernate bringt die Abhängigkeit jboss-logging in den Klassenpfad, aber Logback wird bereits intelligent verwendet, wenn es vorhanden ist. c3p0 muss jedoch zusätzlich mit com.mchange.v2.log.MLog = com.mchange.v2.log.log4j.Log4jMLog konfiguriert werden, um seine Logeinträge in log4j zu senden, die dann von 'log4j = & gt; slf4j 'Brücke.
Wenn Sie log4j-over-slf4j verwenden , c3p0s MLog loggt sich auf das "gefälschte" log4j ein, welches wiederum slf4j sein wird, dann können Sie den Provider verwenden, den Sie für die Ausgabe von slf4j bevorzugen.
EDIT: Das hat funktioniert, als ich es benutzt habe und diese Antwort eingereicht habe, aber sie haben das ein paar Monate später gebrochen. Weitere Änderungen in FredCooke finden Sie unter Antwort .
Sie können System.err mit System.setErr () auf einen anderen PrintStream zeigen lassen. Es ändert nicht C3PO, aber die Protokollausgabe Ausgabe erscheint dort, wo Sie es wollen.
Tags und Links java slf4j c3p0 java.util.logging