Java 赞成和反对；在服务器级别与应用程序级别配置日志的缺点

在java中配置日志有时会很棘手（由于存在多个日志API），并且可以在不同的级别（服务器、应用程序，两者都可以？）完成。那么，在这些级别配置日志记录的利弊是什么呢

我带来了这个列表，但我希望其他人分享他们的经验：

• 服务器级
  • 专业人士
    • 集中配置
    • 部署前不得修改应用程序
    • 可以登录到服务器管理的资源（相对于服务器路径的文件，DB…）
  • 缺点
    • 必须确保每个应用程序使用相同的日志api
    • 随着部署更多应用程序，配置可能会变得越来越大
    • 服务器可能太了解每个应用程序的categories=>日志级别映射
• 应用程序级别
  • 专业人士
    • 应用程序可以使用自己选择的日志api
    • 应用程序可以配置自己的日志记录级别
  • 缺点
    • 必须在部署之前编辑配置，以便指定日志文件的路径（若相对于服务器）或日志数据库的JNDI名称

有没有办法将两者结合起来，只保留专业人士？比如在服务器级别配置日志记录器，然后在应用程序级别配置categories=>日志级别映射

有没有办法将两者结合起来，只保留专业人士？比如在服务器级别配置日志记录器，然后在应用程序级别配置categories=>日志级别映射

• 要回答这个问题，我会说，是的，我们可以做到。但是在这种情况下，您的服务器和应用程序必须遵循正确的设计，从负面来看，所有应用程序都可能会紧密耦合

如果您的应用程序是基于java的，那么您实际上可以为所有应用程序创建一个单独的记录器文件，并且如果您的应用程序遵循不同的包结构，您必须在其中设置应用程序记录器级别

假设app1遵循包结构com.app1。。和app2跟随com.app2..，然后您可以修改记录器级别，如下所示，

---

但是，如果您的app2依赖于app1，或者它有像com.app1.app2.*这样的包或一些常见的包名，那么您可能需要定义更多关于记录器属性的内容，因此包结构和设计对于遵循单一日志机制非常重要。

在我们的例子中，我们将日志作为一个接口来处理-基本上，开发人员定义登录的内容和通道，然后对每台服务器进行配置。这里的主要问题是，我们从未将任何特定于环境的内容与应用程序一起部署。与此类似，开发和质量保证环境可以将某些通道设置为调试，而实时环境则不能。我发现这是一个非常可行的方法。是什么让您的日志记录配置如此复杂？我手头有一点时间，我喜欢在不做任何修改的情况下将应用程序存档直接放在部署文件夹中（外部资源的配置应该在服务器端进行）。这对于数据库、jms队列、邮件会话来说很容易，我也为ehcache管理器做了这项工作（因为有时它需要将数据持久化到应用程序外部的磁盘）。现在，我正试图为日志记录做同样的事情。。。但我承认这有点不同，也有点困难，因为服务器一启动就需要记录日志（而不需要数据库、队列…）。

*.*.com.app1 = logger_level1
*.*.com.app2 = logger_level2