当前位置:  开发笔记 > 编程语言 > 正文

你发现java.util.logging足够吗?

如何解决《你发现java.util.logging足够吗?》经验,为你挑选了7个好方法。

根据标题,您是否找到了足以满足您需求的默认Java日志框架?

您是否使用其他日志记录服务,如log4j或其他?如果是这样,为什么?我想听听您对不同类型项目中的日志记录需求的任何建议,以及何时集成框架实际上是必要和/或有用的.



1> Huxi..:

java.util.logging(jul)从一开始就没必要了.只是忽略它.

jul本身有以下缺点:

在Java 1.4中引入jul的时候,已经有一个广泛使用的日志框架:LOG4J

预定义的日志级别为:SEVERE,WARNING,INFO,CONFIG,FINE,FINER,FINEST.我不会告诉你我个人对这些预定级别的看法,以保持这个答案的半目标.

可以定义其他级别.jul支持多达4G不同的日志级别,这有点矫枉过正,恕我直言.有时更少.

最重要的一点:如果您敢于定义自己的日志级别,则可能会遇到内存泄漏问题!
请在这里阅读有关此效果的信息:

类加载器泄漏:可怕的"java.lang.OutOfMemoryError:PermGen space"异常

如何修复可怕的"java.lang.OutOfMemoryError:PermGen space"异常(classloader leaks)

这是一个非常有趣的阅读,即使你不打算使用自定义级别,顺便说一句,因为问题是一个广泛的问题,根本不适用于jul.

它驻留在java.*名称空间中,因此无法在运行时交换实现.这有效地防止它以与commons.logging和LOG4J相同的方式桥接到SLF4J.为jul完成桥接的方式会对性能产生影响.这使得jul成为最不灵活的日志框架.

通过引入jul,Sun隐含地将其定义为"标准java日志框架".这导致了一种常见的误解,即"优秀的Java公民"应该在他们的库或应用程序中使用jul.
情况恰恰相反.
如果您使用commons.logging或LOG4j,您将能够通过桥接到SLF4J来交换实际使用的日志框架(如果您需要).这意味着使用commons.logging,LOG4J或SLF4J的库都可以记录到相同的日志记录目标,例如文件.

我个人建议使用SLF4J + Logback组合进行所有日志记录.这两个项目都由LOG4J背后的人CekiGülcü协调.
SLF4J是一个值得(但非官方,因为它不是来自同一组)commons.logging的继承者.它比CL更少问题,因为它静态地解析了实际使用的日志记录后端.此外,它具有比CL更丰富的API.
另一方面,Logback是LOG4J的(非)官方继承者.它本地实现了SLF4J,因此任何包装器都不会产生任何开销.

如果你仍然认为我应得的话,你现在可能会投票给我.;)


好吧,我改变了一点,但它肯定取决于"官方"的定义.Logback站点声明"Logback旨在作为流行的log4j项目的后续版本." 因为Ceki是log4j背后的驱动力,所以我称之为这个漂亮的官方.如果Linus离开Linux基金会(是的,不太可能;))并分叉了一个具有创新功能的新内核,我仍然称该内核是Linux内核的继承者,无论是否得到Linux基金会的批准.Apache的Log4j开发很久以前就停滞了.我称那个项目已经死了.非官方.;)

2> Elijah..:

使用第三方库记录依赖关系

在大多数情况下,Java JDK日志记录本身并不足够.但是,如果您有一个使用多个开源第三方库的大型项目,您将很快发现其中许多具有不同的日志记录依赖项.

在这些情况下,需要从日志记录实现中抽象日志API变得很重要.我建议使用slf4j或logback(使用slf4j API)作为您的API,如果您想坚持使用Java JDK日志记录,您仍然可以!Slf4j可以毫无问题地输出到许多不同的记录器实现.

在最近的一个项目中发生了一个有用的具体例子:我们需要使用需要log4j的第三方库,但是我们不想并行运行两个日志框架,所以我们使用了slf4j log4j api包装器库和问题解决了.

总之,Java JDK日志记录很好,但是我的第三方库中使用的标准化API将为您节省时间.试着想象重构每个日志声明!



3> sblundy..:

SLF4J是新生儿.我已经完成了一些工作,它非常好.它的主要优点是参数化日志记录,这意味着你这样做:

logger.debug("The new entry is {}. It replaces {}.", entry, oldEntry);

而不是这个:

logger.debug("The new entry is " + entry + ". It replaces " + oldEntry + ".");

并且只有在实际记录语句时才执行所有字符串操作.看起来也更干净.

应该注意的是,SLF4J是一个类似于commons-logging的包装器,尽管它声称不太容易出现commons-logging的类加载器问题.


SLF4J的消息格式化程序比java.util.Formatter快10倍.它实际上最终会产生可衡量的差异.
可以使用消息格式化程序在"标准"日志记录之上构建它.

4> 小智..:

我们始终使用java.util.logging.也适用于大型项目.你应该调整一些东西(例如默认格式),但这不是真正的要点.我发现Java中的日志记录框架的数量和它们实现的功能蠕变相当令人烦恼,并且对Java社区有点尴尬.关于伐木的宗教辩论水平是一个严重错误的确定迹象.

JUL为您提供的是一个简单但足够的API和一个单独的位置来配置您想要查看的日志输出(logging.properties或JMX ...).它始终存在且稳定.

所有想要记录的代码都应该遵循标准约定(默认级别为INFO),否则不会再使用有意义名称的记录器(例如包或类名),你会没事的.



5> TofuBeer..:

除非有令人信服的理由使用JDK以外的东西,否则我更喜欢使用Sun提供的东西.

许多使用Log4J日志记录的项目都在"标准"日志记录API存在之前使用它.



6> John O..:

JDK日志记录工具总是完成我需要他们做的事情 - 从来没有遇到过问题.

对我来说,第三方记录工具既不必要也不可取.


commons-logging和更新的SLF4J中的值是它们不是*第三方日志工具,并且允许独立于第三方日志记录工具实现第三方库(使用日志记录).如果你正在开发一个应用程序,请务必使用jul,或log4j,或者其他任何东西 - 选择一个.如果您正在开发一个库,并打算让该库对其他应用程序有用,请不要对特定的日志记录实现做出任何假设 - 并写入一个公共接口.见"大卫a."的回应.

7> Michael Shar..:

我无法弄清楚如何控制java.util.logging框架中各个类的日志记录级别,这在log4j中是可能的.如果我有诊断错误麻烦或有它记录重要信息的高流量的课,我可以改变级别的单一类日志越来越离开了课堂的休息相对平静.

NB可能是我无法弄清楚如何做到这一点,或者java.util.logging可能已经改变,因为我尝试过.

推荐阅读
携手相约幸福
这个屌丝很懒,什么也没留下!
DevBox开发工具箱 | 专业的在线开发工具网站    京公网安备 11010802040832号  |  京ICP备19059560号-6
Copyright © 1998 - 2020 DevBox.CN. All Rights Reserved devBox.cn 开发工具箱 版权所有