英文:
Issue with log4j2 config when used with Java modules (JPMS) & Gradle
问题
我使用Gradle创建了一个普通的Java项目，然后将该项目转换为使用Java模块。在没有模块的情况下，位于项目根目录的log4j2.xml会被使用。
但是一旦我将应用程序转换为基于模块的系统，框架不再使用我的log4j2.xml，而是使用其自己的默认配置。
据我所了解，在Java平台模块系统（JPMS）中，当我们尝试使用Module#getResourceAsStream访问资源时，那些不位于与包相匹配的路径下的资源（例如模块根目录下的根级资源/myfile.txt）以及当涉及模块根目录下的/META-INF文件夹时，这些资源会自动对调用模块可用（如果我有误，请纠正我）。但是我不确定JPMS在决定查找给定资源的哪些模块时使用了哪种方法（是否是全部？还是有其他机制？）。
在我的情况下，我导出并打开了该模块，只是为了检查是否导致了这个问题。不幸的是，那不是原因。
你知道可能是什么原因吗？
可以在以下GitHub存储库中找到此问题的源代码：
https://github.com/thekalinga/log4j2-config-gradle-jpms-issue
英文:
I created a vanilla java project using gradle & then converted the project to use java modules. Without modules, the log4j2.xml thats present at the root of the project is picked up.
But once I converted the application to module based system, instead of picking my log4j2.xml, the framework is using its own default config.
It is my understanding that in Java Platform Module System (JPMS) [When we attempt to access a resource using Module#getResourceAsStream, the resources that which are not under a path that matches a package (say a root level resource in /myfile.txt at module root) & also when it comes to /META-INF folder at module root will be automatically made available to the caller module (Please correct me if I am wrong). But I am not sure about the methodology JPMS uses when deciding which modules to look up for a given resource (is it all? or does it have some other mechanism?).
In my case, I both exported & opened the module just to check if that was causing the issue. Unfortunately, that's not the reason
Any idea why this might be the case?
The source for the issue can be found at the following github repo
https://github.com/thekalinga/log4j2-config-gradle-jpms-issue
答案1
得分: 1
抱歉，我只能返回你要求的翻译内容，不过我注意到你的原始文本中包含了一些编码字符（如'和"），我会将它们解码后再进行翻译：
我无法百分之百确定，因为我还没有完全调查过，但我猜测，与大多数其他库一样，Log4j 2 2.x可能不完全支持JPMS。使用JPMS时，每个模块都由自己的ClassLoader管理。由于Log4j是一个自动模块，它将与所有其他自动模块分组，但不会与“真正的”JPMS模块分组。这意味着当Log4j尝试定位“类路径”上的log4j2.xml时，它只会找到位于其他自动模块中的文件，因为Log4j 2 2.x不支持定位其他模块中的文件。
如果您的应用程序被定义为JPMS模块（即带有module-info.class文件），那么Log4j将无法定位位于其中的配置文件。
Log4j 2.3.0的开发已经进行了相当长的时间。始终的意图是完全支持JPMS，因此您应该期望在最终发布时它能够正常工作，但是使诸如Log4j之类的库完全支持JPMS需要相当多的工作。由于所有Log4j开发人员都是在业余时间支持它，因此找到足够的时间来处理我们想要的所有内容可能会具有挑战性。
英文:
I can't say with certainty because I haven't investigated it fully yet, but my guess is that, like most other libraries, Log4j 2 2.x doesn't fully support JPMS. With JPMS each module is managed by its own ClassLoader. Since Log4j is an automatic module it will be grouped with all other automatic modules but not with "true" JPMS modules. This means that when Log4 tries to locate the log4j2.xml on the "classpath" it will only find files located in other automatic modules because Log4j 2 2.x doesn't have support for locating files in other modules.
If your application is defined as a JPMS module (i.e. with a module-info.class file) then Log4j won't be able to locate a configuration file located within it.
Log4j 2 3.0 development has been underway for quite some time. The intention with it has always been to fully support JPMS so you should expect this will work when it is finally released, but getting libraries like Log4j to fully support JPMS requires quite a bit of work. As all the Log4j developers support it in their free time finding enough of it to work on everything we want can be challenging
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论