Java FileHandler向文件名添加不必要的数字 [英] Java FileHandler Adding Unnecessary Digit to File Name
问题描述
我正在与JUL一起进行日志记录(不，我无法更改).我已经开发了一个简单的包装器，可以传入参数，并且每次都使用正确的格式创建FileHandler，这样我就不必在每个项目中都重新创建日志记录.
I'm working with JUL for my logging (no I can't change that). I've developed a simple wrapper that I pass in the parameters and it creates the FileHandler with the correct format every time so that I don't have to recreate the logging in every project.
我的测试应用程序的功能完全符合预期，但是当我将库导入其他项目时，我似乎遇到了一个(到目前为止只有一个)独特的错误:每一次，它都会在末尾添加".0"日志文件.
My test app functions exactly as intended, but when I import the library into other projects I seem to be getting one (only one so far) unique error: Every single time, it adds a ".0" to the end of the log file.
即使没有冲突并且Filehandler已配置为将现有文件附加到末尾(这样做很好)，它也会执行此操作.我玩过各种各样的文件名，最近我一直在使用简单的"mylog.log"，日志文件仍然输出为"mylog.log.0".我已经检查过，并且将文件处理程序传递给了正确的文件("mylog.log")，但该文件未在此处记录.
It does this even when there is no conflicts and the Filehandler has been configured to append to the end an existing file (which it does fine). I've played with various file names, most recently I've been using the simple "mylog.log" and the log file still gets output as "mylog.log.0". I've checked and the fileHandler is being passed the correct file ("mylog.log"), but it isn't logging there.
在日志记录测试中不会发生这种情况，只有在我实际上想在其中使用它的项目中才会发生.即使使用完全相同的参数，我也会得到不同的文件名.
This does not happen in my logging test, only in the project I actually want to use it in. Even when using the exact same parameters, I get different file names.
我缺少一些有关JUL的怪癖吗?代码很简单.相关代码:
Is there some quirk about JUL that I'm missing? Code is very simple. Relevent code:
String logFilePath = directory+name; // directory and name are method arguments
Handler newFileHandler;
File dirFile = new File(directory);
if(!dirFile.exists())
{
dirFile.mkdirs();
}
newFileHandler = new FileHandler(logFilePath, true);
newFileHandler.setFormatter(myformatter);
//... etc
推荐答案
我最终发现了这一点，却忘记了原因.
I eventually figured this out and forgot to post the cause.
有两件事在起作用:
-
由于我所处的环境，滚动"日志记录被我不知道的一些后台变量激活，因此为什么在不应该添加".0"的情况下添加它曾经，但是只有在将其从测试中移到实际的实施项目中后，我才看到它.
Due to the environment I was in, the "rolling" logging was being activated by some back ground variables I wasn't aware of, hence why the ".0" was being added when it shouldn't have been, but I only saw it once I moved it out of testing and into the actual implementing project.
JUL的工作方式极其灵活.真的，我对此不能说得很烂.总之，长话短说，如果启用了滚动日志记录，它将始终附加文件号，以使活动日志以".0"结尾.通常，我使用的API仅在辅助日志中具有该编号，而当前日志将保持您给它的确切名称-这给我造成了一些麻烦，因为JUL 也没有获取当前日志"文件"方法来获取活动文件的名称，因此我需要创建一个丑陋的方法来根据参数预测名称应该是什么，并希望不会出错.顺便说一句，您不能更改世代号的格式(这也引起了我一些问题，因为首选文件号为01，02，... 10，11而不是0,1,2，...). 10).
JUL is ridiculously inflexible in how it works. Really I can't speak poorly enough about it. Anyway, long story short, if rolling logging is enabled it will always append a file number such that the active log ends in ".0". Typically I've used APIs that only had the number on the secondary logs, while the current log would maintain the exact name you gave it - this caused me some trouble as JUL also has no "get current log file" method to get the name of active file, so I needed to create an ugly method that predicted what the name should be based on the parameters, and hope nothing went wrong. As an aside, you cannot change the format of the generation numbers (which also caused me some issue as it was preferred to have the files number 01, 02, ... 10, 11 rather than 0,1,2,...10).
这篇关于Java FileHandler向文件名添加不必要的数字的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
