Ich sehe ein ziemlich seltsames Problem.Java-Datei-Logger wird entführt und in eine Datei eines anderen Loggers (von Gigaspaces API) nach der Erstellung umgeleitet
Ich habe einige Standard-Java-Logger (mit Logger.getLogger(), einem FileHandle und einem SimpleFormatter) erstellt. Die funktionieren gut, und die Protokolldatei wie erwartet ausgeben.
Dann habe ich einige Klassen aus der Gigaspaces-API (com.gigaspaces.gs-openspaces - enthalten über eine Maven-Abhängigkeit), die eine eigene Protokollierung enthält. Danach endete die gesamte Ausgabe meiner Logger in der Gigaspaces Logdatei (zB ~/.m2/repository/com/gigaspaces/logs/2017-03-27 ~ 12.46-gigaspaces-service-135.60.146.142-23534 .log) statt in den entsprechenden Protokolldateien, die sie verwenden sollen.
Wenn ich dann nach der Initialisierung von Gigaspaces weitere Logger erstelle, funktionieren diese neuen Logger wie erwartet. Es sind nur Logger betroffen, die vor der Initialisierung von Gigaspaces erstellt wurden.
Ich habe versucht, im Code für Gigaspaces ein bisschen herumzustochern, da ist eine Menge Code drin. Ich habe nichts sofort offensichtlich gesehen.
Mache ich etwas falsch mit der Einrichtung meiner Logger? Es scheint nicht richtig zu sein, dass eine Bibliothek die Ausgabe von bereits existierenden Loggern stehlen kann, die nicht mit ihren Klassen zusammenhängen.
Das unten kurze Testprogramm demonstriert das Problem:
Logger testLog = Logger.getLogger("testlog");
try {
FileHandler fh = new FileHandler("testlog.log");
fh.setFormatter(new SimpleFormatter());
testLog.addHandler(fh);
}
catch (Exception e) {
// Not important
e.printStackTrace();
}
testLog.log(Level.INFO, "This appears in the main log file");
// Spin up gigaspaces, even by trying to connect to a space that doesn't exist
UrlSpaceConfigurer testSpaceConfigurer = new UrlSpaceConfigurer("jini://*/*/testSpace?locators=127.0.01").lookupTimeout(1);
try {
GigaSpace g = new GigaSpaceConfigurer(testSpaceConfigurer).gigaSpace();
}
catch (Exception e) {
// This will throw an exception, just ignore it.
}
testSpaceConfigurer.close();
testLog.log(Level.INFO, "This appears in the (wrong) gigaspaces log file");
Ich denke, dass GigaSpaces ein anderes Logging-Framework (Log4j, Logback, was auch immer) verwendet, das standardmäßig die Logging von anderen Diensten zu seinem Framework umleitet. – john16384
Ich habe überprüft, und es scheint keine Abhängigkeiten zu log4j oder einem anderen Framework zu haben. Es hat eine transitive Abhängigkeit von (Avalon) LogKit. Ich versuchte das durch Maven auszuschließen, und das machte keinen Unterschied. –