在运行时通过指定路径加载log4j2.xml或properties配置文件
我正在尝试从运行时提供的特定位置加载 log4j2.xml 或属性文件。 这是从 log4j 1.x 到 log4j 2.x 版本迁移的一部分。我发现 log4j2 中的日志配置加载顺序有很多变化。所以现在搜索后我有以下方法 -
1 -
Configurator.reconfigure(new URI("URI of your file"));
2 -
// import org.apache.logging.log4j.core.LoggerContext;
LoggerContext context = (org.apache.logging.log4j.core.LoggerContext) LogManager.getContext(false);
File file = new File("path/to/a/different/log4j2.xml");
// this will force a reconfiguration
context.setConfigLocation(file.toURI());
但他们说 LoggerContext 类不是公共 API 的一部分，现在仍然是这种情况吗？
3-
InputStream inputStream = new FileInputStream("C:/path/to/log4j2.xml");
ConfigurationSource source = new ConfigurationSource(inputStream);
Configurator.initialize(null, source);
4- 或者只是
Configurator.initialize(null, "/path/to/log4j2.xml");
我很困惑，如果所有这些都是可行的，或者是否要在不同的场景中使用并产生不同的结果。
我试图替换的功能还有 DOMConfigurator 和 PropertyConfigurator。我知道 log4j2 会在类路径中自动查找配置，但如果我有针对不同环境等或场景的多个配置文件，或者配置文件位于类路径之外、系统上的其他位置 - 我正在尝试使用上述函数来执行此操作。 请帮忙，因为我被困在这里，谢谢。
I am trying to load log4j2.xml or properties file from a specific location which will be provided at runtime.
This is part of a migration from log4j 1.x to log4j 2.x version. I have seen there are lots of changes in the logging configuration loading sequences in log4j2. So right now after searching I have the following methods below -
1 -
Configurator.reconfigure(new URI("URI of your file"));
2 -
// import org.apache.logging.log4j.core.LoggerContext;
LoggerContext context = (org.apache.logging.log4j.core.LoggerContext) LogManager.getContext(false);
File file = new File("path/to/a/different/log4j2.xml");
// this will force a reconfiguration
context.setConfigLocation(file.toURI());
But they say that LoggerContext class is not part of the public API, is it still the case now ?
3-
InputStream inputStream = new FileInputStream("C:/path/to/log4j2.xml");
ConfigurationSource source = new ConfigurationSource(inputStream);
Configurator.initialize(null, source);
4- Or simply
Configurator.initialize(null, "/path/to/log4j2.xml");
I am confused if all of these are viable or are to be used in different scenarios and have different outcomes.
Also the functions that I am trying to replace are DOMConfigurator and PropertyConfigurator. I know log4j2 will find configurations automatically in classpath but incase I have multiple configuration files for different environments etc or scenarios or the configuration file is outside the classpath, somewhere else on the system - I am trying to use these above functions to do it.
Please help as I am stuck here, thank you.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
如果没有
LoggerContext与调用者关联，则所有这些方法都具有相同的效果：它们创建一个LoggerContext并使用提供的配置源对其进行配置。如果有一个 LoggerContext 与调用者关联，这 4 个方法就会开始有所不同。如果之前调用了任何
LogManager的get*方法（例如在静态初始化程序中），则可能会发生这种情况。如果发生这种情况，前两个方法将替换该上下文的配置，而后两个方法则不执行任何操作。Log4j 1.x 中的
PropertyConfigurator和DOMConfigurator工作方式不同：除非您使用log4j.reset=true键，否则它们会修改之前的配置。尽管这两个类已移植到最新的log4j-1.2-api，但“重置”语义尚未实现，并且它们的行为类似于仅限于单个配置的Configurator.reconfigure格式。备注：
Configurator.reconfigure尝试猜测配置格式以选择合适的ConfigurationFactory。由于 Log4j 2.x 和 Log4j 1.x 都具有属性和 XML 格式，因此所有属性和 XML 文件都将解释为本机 Log4j2 配置文件。检查此问题以获取解决方法。If no
LoggerContextis associated with the caller, all these methods have the same effect: they create aLoggerContextand configure it using the configuration source provided.The 4 methods start to differ if there is a
LoggerContextassociated with the caller. This can happen if anyLogManager'sget*method was called before (e.g. in a static initializer). If this happens, the first two methods will replace that context's configuration, while the last two are no-ops.PropertyConfiguratorandDOMConfiguratorin Log4j 1.x worked differently: unless you usedlog4j.reset=truekey they modified the previous configuration. Although the two classes have been ported to the newestlog4j-1.2-api, the "reset" semantic is not implemented and they behave likeConfigurator.reconfigurerestricted to a single configuration format.Remark:
Configurator.reconfiguretries to guess the configuration format to choose the appropriateConfigurationFactory. Since both Log4j 2.x and Log4j 1.x have the properties and XML formats, all properties and XML files will interpreted as native Log4j2 configuration files. Check this question for a workaround.