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

Question

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

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

然后，我使用了Gigaspaces中的一些类(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之前创建的记录器才会受到影响。

我尝试了一下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

按照jmehrens的建议，凌驾于安全管理器之上似乎是可行的。通过拒绝在LogManager上运行reset()方法的权限，我能够阻止Gigaspaces窃取日志记录，因此：

// 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.");
                    }
                }
            }
        }
    });
}

在这种情况下，我只是在创建gigaspace实例的类的静态块中添加了覆盖，但是在初始化它们之前的任何地方都可以。

Answer 2

您必须使用固定“测试日志”记录器，否则可能会丢失应用到它的所有更改。

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

如果GigaSpaces正在调用LogManager.reset()，那么删除处理程序的一个讨厌的、难闻的、肮脏的方法就是扩展FileHandler并覆盖等于。

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