Java文件记录器在创建后被劫持并重定向到属于另一个记录器(来自Gigaspaces API)的文件

Question

我看到了一个相当奇怪的问题。

我创建了一些标准的Java记录器(使用Logger.getLogger()，FileHandle和SimpleFormatter)。 这些工作正常，并按预期输出日志文件。

然后，我使用了来自Gigaspaces API的一些类(com.gigaspaces.gs-openspaces - 通过Maven依赖项包含)，其中包括自己的日志记录。 之后，我的记录器的所有输出都位于Gigaspaces日志文件中(例如~/.m2/repository/com/gigaspaces/logs/2017-03-27~12.46-gigaspaces-service-135.60.146.142-23534.log)，而不是它们应该使用的适当日志文件中。

如果我在初始化 Gigaspaces 后创建更多记录器，这些新的记录器将按预期工作。 只有在初始化千兆空间之前创建的记录器才会受到影响。

我尝试在Gigaspaces的代码中闲逛了一下，里面有很多代码。 我没有看到任何立即明显的东西。

我在设置记录器时做错了什么吗？ 库可以从与其类无关的预先存在的记录器中窃取输出似乎是不对的。

下面的简短测试程序演示了该问题：

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");

Answer 1

您必须固定"testlog"记录器，否则您可能会丢失应用于它的所有更改。

修改记录器需要权限。 一种选择可能是使用自定义安全管理器，该管理器不允许GigaSpaces重定向您的日志记录。

如果GigaSpaces正在调用LogManager.reset()，那么删除处理程序的一种黑客，臭味，肮脏的方法是扩展FileHandler并覆盖equals。

public class GigaSpaces {
//Pin the logger
private static final Logger testLog = Logger.getLogger("testlog");
static {
try {
FileHandler fh = new FileHandler("testlog.log") {
public boolean equals(Object o) {
return false; //Pure Evil.
}
};
fh.setFormatter(new SimpleFormatter());
testLog.addHandler(fh);
}
catch (Exception e) {
// Not important
e.printStackTrace();
}
}
public void foo() throws Throwable {
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.
} finally {
testSpaceConfigurer.close();
}
testLog.log(Level.INFO, "This appears in the (wrong) gigaspaces log file");
}
}

Answer 2

正如 jmehrens 所建议的那样，覆盖安全管理器似乎是要走的路。 我能够通过拒绝 Gigaspaces 在日志管理器上运行 reset() 方法的权限来阻止它窃取日志记录，因此：

// Silly hack to keep gigaspaces from STEALING ALL OUR LOGS
static {
System.setSecurityManager(new SecurityManager() {
@Override
public void checkPermission(Permission p) {
if (p instanceof LoggingPermission) {
for (StackTraceElement stackTraceElement : new Exception().getStackTrace()) {
if (stackTraceElement.getMethodName().equalsIgnoreCase("reset") && stackTraceElement.getClassName().equalsIgnoreCase("java.util.logging.LogManager")) {
throw new SecurityException("No resetting the logger!  It is forbidden.");
}
}
}
}
});
}

在这种情况下，我只是在创建我的千兆空间实例的类的静态块中添加了覆盖，但在初始化它们之前的任何地方都应该这样做。