电子技术论坛_中国专业的电子工程师学习交流社区-中电网技术论坛

标题: WebSphere Application Server 日志记录开发人员指南（2） [打印本页]

作者: look_w 时间: 2018-8-13 21:16 标题: WebSphere Application Server 日志记录开发人员指南（2）

选择正确的日志和跟踪 API最常见的日志记录 API 有哪些？
有多个日志记录 API 选项可以在 WebSphere Application Server 应用程序中使用。最常见候选选项如表 1 中所示。
表 1. 日志记录 API日志记录 API是否与 WebSphere Application Server 日志集成是否建议在 WebSphere Application Server 应用程序中使用java.util.logging (JUL)是（从 V6.0 起）是（V6.0 或更高版本）JRAS是是（仅仅适用于 V6.0 之前的版本）Log4J否否Jakarta Commons Logging (JCL)是否System.out.println and System.err.println是否

java.util.logging (JUL)
JUL 从 2002 年 J2SE 1.4 发布之后一直是 Java SDK 的标准组成部分。从体系结构的角度而言，它与 Log4J 类似。JUL API 包含五个主要概念：记录器、处理器、筛选器、格式设置器和日志记录。JUL 的主要优势是，基于 J2SE 1.4（或更高版本）的所有运行时都将其包含在其中，提供了支持日志记录设置控制的灵活体系结构，而且能够方便地进行自定义。
JUL 是 WebSphere Application Server 中的首选日志记录实现，而且在 WebSphere Application Server 自己的实现中使用。JUL 的日志记录使用非常简单，而且具有足够的自定义能力，能满足大部分日志记录需求。JUL 与 WebSphere Application Server 实现了很好的集成，任何对 JUL 记录器 API 的任何请求（甚至包括来自应用程序代码的请求）都将由 WebSphere Application Server 日志记录基础设施进行处理。对于任何将在 WebSphere Application Server 内操作的新应用程序代码，都强烈建议使用 JUL。
JRAS
JRAS 是从 V3.5 之后随 WebSphere Application Server 提供的公用 API。JRAS API 及其所基于的 API 是 Log4J 和 JUL 的前身。JRAS API 已在 WebSphere Application Server V6.0 弃用，应用服务器将转而利用 JUL API。因此，不要对任何新代码使用 JRAS。
Log4J
Log4J 是一个 Apache 项目，旨在提供灵活而强大的日志记录实现。Log4J 最初在 1999 年发布，其体系结构与 JUL 类似。JUL 具有记录器、处理器、格式设置器和日志记录，而与此对应，Log4J 具有记录器、追加器、布局和日志记录事件。Log4J 的标准配置中包含很多追加器和布局。
Log4J 作为 Apache 的开源项目提供，但并不属于 Java 语言标准。Log4J 的主要优势在于，它提供与 JUL 类似的功能，而且具有大量的预先构建的追加器和布局实现。
虽然体系结构与 JUL 类似，但 Log4J 并未与 WebSphere Application Server 日志记录基础设施集成。通常，除非迫切需要 Log4J 的追加器或布局的高级功能，否则请不要将 Log4J 与 WebSphere Application Server 一起使用。您可能决定将 Log4J 和 WebSphere Application Server 结合使用，然后发现能够正常工作，但您并不能获得 JUL 所利用的集成所带来的好处。
Jakarta Commons Logging (JCL)
JCL 是旨在提供可编写的包装 API 的 Apache 项目。与其他日志记录 API 不同，JCL 在运行时就将日志记录呼叫委派给适合包含环境的具体日志记录实现。例如，在 WebSphere Application Server 中，JCL 的事件将发送到 WebSphere Application Server 日志和跟踪工具。在其他环境中，将 JCL 输出发送到 Log4J 的做法并不常见。这里的要点是，JCL 并不是基于标准的 API，而是让开发人员“不必担心”其跟踪输出的输出位置的框架。JCL 在标准 API 之前就存在。
JCL 的主要优势是，它允许代码使用日志记录调用进行检测，而且不用考虑在运行时存在哪些日志记录工具，或代码将最终在哪些运行时上运行。
JCL 与 WebSphere Application Server 集成并打包在一起。绑定自己的 JCL JAR 副本并希望将输出发送到不是 IBM 提供缺省项的目的地的应用程序需要特别谨慎，以避免与应用服务器运行时中包括的 JCL 版本出现类加载冲突。这通常很难很好地完成，因此不建议这样做。
由于在所有 J2SE 1.4 和较高版本的 JVM 都提供 JUL，就减少了将 JCL 作为可移植日志记录包装的需求。因此，不要在任何新的应用程序代码中使用 JCL。
System.out.println and System.err.println
虽然这不是真正的日志或跟踪 API，但很多开发人员都喜欢使用 System.out.println 检测其代码。WebSphere Application Server 将对传递给 System.out 和 System.err 的数据进行充实。WebSphere Application Server 不会将 System.out 和 System.err 写到控制台，而会：
- 将传递到每个流的数据转换为日志事件（不精确进程）。
- 确定事件的创建时间。
- 确定事件发出者的线程 ID。
- 将事件连同上述信息写入托管日志文件。
不过，应用服务器并不能使用 System.out 和 System.err 确定消息的准确来源（类或方法），无法确定消息的严重程度，而且无法提供比基本的开/关功能（服务器范围内）更强的功能来控制这些消息的输出。或许最重要的是，将大量跟踪输出发送到 System.out 开销非常大，而且将导致大量的性能问题（并需要面临减少输出量的压力）。这些差异使 System.out 和 System.err 不适合大规模使用。因此，不要在应用程序代码中使用 System.out.println 和 System.err.println。

应该将哪个日志记录 API 用于 WebSphere Application Server？
正如上面所述，有各种日志记录可供选择。以下是 WebSphere Application Server 服务能力团队针对应用程序代码的建议：

将 JUL 用于将在 WebSphere Application Server V6.0 或更高版本上运行的新代码。
由于 JUL 的普遍性及与应用服务器日志和跟踪工具的紧密集成，因此 JUL 是最适合用于新 WebSphere Application Server 应用程序代码的 API。只有在应用程序所需的所有运行时中都不提供 JUL 时才应考虑其他日志记录 API。
如果（且仅在此情况下）需要支持不能正确支持 JUL 的环境，则请对新代码继续使用现有日志记录框架。
通常，如果继续部署到 J2SE 1.4 之前的环境，则您已经具有其他应用程序和已经建立的日志记录 API。您有两个选择，一个是继续使用现有日志记录 API，另一个是寻找其他 API。既然 JUL 中有日志记录标准，则投资新的日志记录基础设施就不那么急迫了，因为任何投资都将只是暂时性的。
不要出于日志记录 API 纯净度的原因替换数千行经过测试的日志记录和跟踪检测的代码行。
对于迁移到支持 JUL 的应用服务器的情况，可能很想对现有日志和跟踪检测进行重新设计。由于要在一个日志记录 API 进行标准化而重写数千行跟踪代码（而且必须进行重新测试），这样的做法通常并不能很好地利用开发资源。在可能的情况下，请考虑将现有的日志记录 API 过渡到采用 JUL 编写代码。如果您无法通过 JUL 整合日志事件，则可以使用 Log Analyzer 之类的工具在查看时将日志与应用服务器日志合并。

欢迎光临电子技术论坛_中国专业的电子工程师学习交流社区-中电网技术论坛 (http://bbs.eccn.com/)