【问题标题】:How to validate Java logging properties files?如何验证 Java 日志记录属性文件?
【发布时间】:2010-12-16 12:09:42
【问题描述】:

我有一个基本功能,允许用户远程将更改应用到我的应用程序中的日志文件。有些日志是使用 java.util.logging 属性文件配置的,有些是使用 log4j/log4cplus 样式的属性文件配置的。我想对用户尝试应用的属性进行一些基本验证。即,我想保证以下几点:

  • 每个 logging.properties 文件必须始终至少包含一个根记录器/日志记录级别
  • 记录器/级别必须设置为有效值。也就是说,他们不应该设置 .level = GIBBERISH 或类似的东西。
  • 我可能会允许他们设置 MaxFileSize 和 MaxBackupIndex (log4j),以及 .limit 和 .count 属性 (java.util.logging)。

实现此目的的最佳方法是什么?我显然可以遍历 Properties 对象中的键和值,并在硬编码的 Map 或其他一些告诉有效属性的数据结构中查找它们的值,但我正在尝试提出一个解决方案比这更优雅一点。

【问题讨论】:

  • XML Log4j 配置格式能坚持吗?
  • 可能不会。不过,也许在未来的版本中,所以如果你有这些方面的建议,我会考虑。

标签: java configuration logging log4j java.util.logging


【解决方案1】:

对属性文件运行任何部分语法检查的问题在于,除非您捕获日志记录系统可接受的每个部分变化,否则它们将始终是不够的,在这种情况下,您将重新创建一部分日志系统。无论您选择验证什么属性,都必然会有其他方法来提交损坏的文件。

为什么不根据输入文件创建一个额外的(临时的,仅用于检查范围内的)记录器对象并检测它是否抛出错误,而不是测试单个属性?

【讨论】:

  • 我喜欢这个想法,但可能我对实现它的 API 不够熟悉。如何使用一组上传的属性创建临时记录器?我在 API 文档中没有看到任何明显的方法。
  • @Steve B - 你的推理+1;不幸的是,问题是 java.util.logging.LogManager 和 Log4j 的 PropertyConfigurator 都没有抛出实际的异常。他们都忽略了任何他们不理解的东西,在某些情况下最多将错误打印到 System.err。
【解决方案2】:

“优雅”的解决方案是编写一个基于规则的引擎来检查名称-值对集合。但是对于这个用例来说,IMO 完全是最重要的......除非检查比我想象的复杂得多。

我想说简单(不优雅)的解决方案在这种情况下是最好的。

【讨论】:

    猜你喜欢
    • 2010-10-31
    • 2020-06-23
    • 2022-06-28
    • 1970-01-01
    • 2021-09-05
    • 2017-11-16
    • 2018-03-20
    • 1970-01-01
    • 2013-10-22
    相关资源
    最近更新 更多