自定义位置中的 Log4j 属性
我将 Apache Commons Logging 和 SLF4J 与 log4j 一起使用，但我也想在自定义位置（如 conf/log4.properties）使用 log4j.properties。 问题是：
如果我使用，
PropertyConfigurator.configure("conf/log4j.properties");
那么我的应用程序将与 log4j 绑定，并且违背了 ACL 和 SLF4J 的目的。
在应用程序不知道日志记录实现是什么的情况下配置它的最佳方法是什么？
I'm using Apache Commons Logging and SLF4J with log4j, but I also want to use the log4j.properties in a custom place like conf/log4.properties. Here is the problem:
If i use
PropertyConfigurator.configure("conf/log4j.properties");
then my app is tied to log4j and defeats the purpose of having ACL and SLF4J.
What is the best way to configure it without the app ever knowing what the logging implementation is?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我认为最简单的方法是使用 log4j.configuration 系统属性指定文件的位置。 采用Log4J手册中的示例：
我相信Log4J会找到一个名为“log4j.properties”位于类路径的任何位置，但可能是幻觉。 不过，值得尝试。
I think the easiest thing to do is specify the location of the file using the log4j.configuration system property. Adopting the example in the Log4J manual:
I believe that Log4J will find a file named "log4j.properties" anywhere on the classpath, but may be hallucinating. Worth trying, however.
指定配置文件位置
您可以使用 VM 参数
-Dlog4j.configuration="file:/C:/workspace3/local/log4j.properties"You can specify config file location with VM argument
-Dlog4j.configuration="file:/C:/workspace3/local/log4j.properties"正如您所说，通过调用
PropertiesConfigurator，您将应用程序绑定到 log4j。 然而，这种联系的延伸是相当有限的。 您可以非常轻松地删除调用PropertiesConfigurator的行并重新编译代码。 完成之后，假设您使用 SLF4J API 进行日志记录，您可以使用另一个日志记录框架（例如 logback-classic 或 jul）替换 log4j，只需替换 jar 文件即可。 因此，SLF4J 在很大程度上仍然发挥其作用。 我不会把婴儿和洗澡水一起倒掉。As you state, by invoking
PropertiesConfigurator, you are tying your application to log4j. However, the extend of this tie is quite limited. You could very easily remove the line invokingPropertiesConfiguratorand recompile your code. After that is done, assuming you are using the SLF4J API for logging, you could repalce log4j with another logging framework, say logback-classic or j.u.l. just by replacing jar files. Thus, SLF4J still serves its purpose to a large extend. I would not throw the baby out with the bath water.