3

我有一个具有多个依赖项并用于log4j.properties控制输出的 Maven 项目。在某些情况下，相同的类可能会在具有不同参数的不同属性文件中被引用。是否有“覆盖”属性的定义协议，还是取决于加载包的顺序？

（我log4j.properties直接在下面src/main/resources- 这是正确的地方吗？）

更新：我已经接受了@Assen 的回答，因为这很有意义，尽管它不会使解决方案变得简单。本质上，他建议从 jar 中排除 log4j.properties。原则上我同意，但它给用户带来了控制输出的负担，而且我的大多数用户不知道 Java 是什么，更不用说属性文件了。也许有一种方法可以重命名每个 jar 中的属性文件并使用开关（可能带有 -D）来激活属性。

4

1 回答 1

1

我经常在项目上进行类似的讨论。我认为 log4j.properties 通常是您希望将其排除在应用程序之外的东西，而不是将其打包在战争中并将其与代码一起交付。日志配置：

  • 是特定于环境的。当您编写应用程序时，您根本无法定义所需的附加程序、文件位置等。
  • 它的生命周期与应用程序的生命周期完全不同。部署应用程序后，日志记录属性一天可以更改数次。重新部署应用程序不应覆盖您上次的日志记录设置。

那么为什么要将日志配置与您的代码一起打包呢？我通常会在某个地方保留一个配置文件夹，其中包含“dev”、“test-server-01”、“macbook-john”等子文件夹。每个子文件夹都包含列表自己的 log4j.properties 副本。它们都不包含在构建工件 - jar 或战争中。

部署时，将单独交付其中一个子文件夹。对于测试服务器 1，这将是 test-server-01 子文件夹的内容。根据使用的应用程序服务器，将一些文件放在类路径上是一个不同的技巧。

开发时，我注意在路径上设置这些子文件夹之一。当 John 在他的 macbook 上进行开发时，他可能想要将“macbook-jihn”放在类路径中，或者创建一个新的。他可以更改日志记录设置并提交而不会发生冲突。

于 2012-12-04T11:01:37.630 回答