在部署时覆盖 log4j 设置

发布于 2024-08-11 19:34:13 字数 271 浏览 2 评论 0原文

对于部署在大量计算机上的应用程序,我决定使用应用程序包部署标准 log4j.xml 文件,只是为了确保各处都存在相同的设置:appender 、类别、级别。

这确实有一个缺点,即在本地修改级别时,我们可能会在重新部署或使用旧设置时丢失更改。在实践中,我们唯一需要更改的是记录器级别,大多数情况下是 1,因此我正在寻找一种解决方案,该解决方案允许我仅覆盖每次安装的级别。

如何在不更改原始 log4j.xml 文件的情况下覆盖 log4j 级别?

For an application which is deployed on a large number of machines I took the decision to deploy a standard log4j.xml file with the application package, just to make sure that have the same settings are present everywhere : appenders, categories, levels.

This does have the downside that when modifying the levels locally we risk losing the changes on re-deploy or living with old settings. In practice, the only thing we need to change are the logger levels, most of the time 1 of them, so I'm looking for a solution which allows me to override just the levels per-installation.

How can I override the log4j levels without changing the original log4j.xml file?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

〃温暖了心ぐ 2024-08-18 19:34:13

设置环境变量 log4j.configuration 以指向外部文件。这样,如果您重新部署,外部文件不会被触及或更改,因此您的配置不会丢失。

有关参考,请参阅 默认初始化过程部分。 ="http://logging.apache.org/log4j/1.2/manual.html" rel="nofollow noreferrer">log4j 手册。

Set the environment variable log4j.configuration to point to an external file. This way if you re-deploy, the external file is no touched or changed and therefore your configuration is not lost.

For reference, see the Default Initialization Procedure section in the log4j manual.

獨角戲 2024-08-18 19:34:13

如果您仍然希望拥有共享的主配置,您可以考虑向应用程序添加一些内容,以允许在初始化后更改 Log4J 记录器级别。您可以通过 JMX 调用这些更改,从集中源获取覆盖,或者只是定期读取本地安装特定的覆盖文件(如果存在),具体取决于您的应用程序可以依赖的基础设施支持。

查看此了解更多信息:

If you still want to have a shared main configuration, you could consider adding something to the application that allowed the Log4J logger levels to be changed after initialization. You could invoke these changes either via JMX, getting the overrides from a centralized source, or simply by periodically reading a local installation-specific override file (if present), depending on what infrastructure support your application can rely on.

Take a look at this for some more information:

枕头说它不想醒 2024-08-18 19:34:13

我曾经通过在 log4j 属性文件中引入另一个间接来解决此类问题。例如,指定

log4j.appender.CONSOLE.Threshold = %level%.

在运行时,我要做的第一件事是替换内存中的占位符,或坚持默认值。这样,log4j 配置在所有部署中都不会改变,包括开发人员、QA 甚至生产。每个目标都有其主要的配置参数集,其中包括级别的%占位符%。这些参数要么随安装程序一起提供,要么每个用户在拉动新版本使用时将主要配置放在一边。但 log4j 配置永远不会改变,除了直接参与它的开发人员之外,没有人接触。

可能我的解释有点太复杂了...将其视为 Spring PropertyPlaceholderConfigurer 并将其应用于 log4j 配置:)

这是一些编码,但非常简单,并且可以解决很多问题。

I used to solve such problems by introducing another indirection into log4j properties file. For example specifying like

log4j.appender.CONSOLE.Threshold = %level%.

At run time, first thing I was doing is replacing the placeholders in memory, or sticking in the defaults. This way log4j configuration never changed throughout all deployments, including developers, QA and even production. Every target would have its main set of configuration parameters, amongst them would be %placeholders% for the level. These parameters would either come with the installer, or each user would keep main configuration aside while pulling the new version to work with. But log4j configuration never changes and nobody touches is except developers who involved directly with it.

May be my explanation is a bit too complicated... think of it as a Spring PropertyPlaceholderConfigurer and apply it to log4j configuration :)

It's a bit of coding, but really simple and solve lots of problems down the road.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文