WebSphere App Server 中的 SLF4J 消息格式

发布于 2024-08-14 19:27:43 字数 1190 浏览 3 评论 0原文

所以,我再次用日志来撞墙。我知道,它能有多复杂?好吧,让我们看看...

我正在启动一个在 WebSphere Application Server 6.1(实际上是 Portal Server 6.1,但底层是 WAS 6.1 - 不管怎样)上运行的新项目。我通常在 WAS 项目中使用 java.util.logging,一切都很好。这位客户是 SLF4J 粉丝并且想要使用它。很公平,听起来很容易。

因此,我将 slf4j-api-1.5.8.jar 和 slf4j-jdk14-1.5.8.jar 部署在 WEB-INF/lib 目录中。在我的代码中,我做了一个 --

// These classes are coming from org.slf4j.*
private static Logger log = LoggerFactory.getLogger(MyClass.class);
...
log.debug("This is a log message");

正如预期的那样,我在 SystemOut.log 中获得了一个条目。但是,我无法弄清楚该消息的格式。一个示例是——

[12/15/09 15:43:15:071 EST] 00000042 MyClass D com.example.MyClass This is a log message

让我解释一下该示例日志条目中的内容。我假设 com.example.MyClass 左侧的所有内容都来自 jul 格式化程序。它右边的所有内容都是我包含在 log.debug() 中的内容。那么,谁添加了com.example.MyClass?我唯一能想到的是 SLF4J 在将消息传递到底层 jul 之前添加它,

这是 com.example.MyClass 部分让我恼火。我不希望将其包含在 SLF4J 生成的日志消息中。类名已经包含在内,因此不需要额外的内容。另外,真正的包名称相当长,它们的包含只会将日志条目的真正内容推到右侧太远。

当我只使用普通的 java.util.logging 时,日志条目与完全相同,除了不包含“com.example.MyClass”部分。正是我想要的!

所以,问题是 - 我怎样才能摆脱 WAS 下通过 SLF4J 生成的日志消息中的这个额外的类名条目?

谢谢!

So, I'm beating my head against the wall with logging again. I know, how complex can it be? Well, let's see...

I'm starting a new project to be run on WebSphere Application Server 6.1 (actually Portal Server 6.1, but it's WAS 6.1 under the hood - whatever). I usually use java.util.logging for my WAS projects and everything is fine. This customer is a SLF4J fan and wants to use that. Fair enough, sounds easy.

So, I deploy slf4j-api-1.5.8.jar and slf4j-jdk14-1.5.8.jar in my WEB-INF/lib directory. In my code I do a --

// These classes are coming from org.slf4j.*
private static Logger log = LoggerFactory.getLogger(MyClass.class);
...
log.debug("This is a log message");

As expected I get an entry in the SystemOut.log. However, it's the format of that message that I can't figure out. A sample would be --

[12/15/09 15:43:15:071 EST] 00000042 MyClass D com.example.MyClass This is a log message

Let me explain what's in that sample log entry. I assume everything to the left of com.example.MyClass is coming from the j.u.l formatter. Everything to the right of it is what I included in my log.debug(). So, who's adding the com.example.MyClass? Only thing I can think is that SLF4J is adding it before it passes the message through to the underlying j.u.l.

It's the com.example.MyClass part that's irritating me. I don't want that included in the SLF4J-generated log message. The class name is already included, so it's extra fluff that's not needed. Plus, the real package names are quite long and their inclusion just pushes the real meat of the log entry too far off to the right.

When I use just plain java.util.loggging, the log entry is exactly the same except that the "com.example.MyClass" piece is not included. Exactly as I want!

So, the question is - how can I get rid of this extra class name entry in the log messages generated via SLF4J under WAS?

Thanks!

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

土豪我们做朋友吧 2024-08-21 19:27:43

您将 slf4j 绑定到 java.util.logging,它很可能是在 WebSphere 内部配置的,因为它看起来不像标准消息格式。

我不了解 WebSphere,但是通过告诉 slf4j 绑定到其他东西可能会得到更好的结果。 slf4j-simple 后端可以吗?它只是打印出信息或更高级别的消息,而不是调用 java.util.logging。

You bind slf4j to java.util.logging which most likely is configured inside WebSphere as it doesn't look like the standard message format.

I do not know WebSphere, but you may get a better result by telling slf4j to bind to something else. Would the slf4j-simple backend do? It just prints out info-or-higher messages instead of invoking java.util.logging.

阿楠 2024-08-21 19:27:43

基本上,您想要配置底层日志记录机制生成的日志消息的布局。

SLF4J 实际上并不执行日志记录,而是委托给其他日志系统(log4j、JUL 等) )取决于您的设置方式。

之一

Basically you want to configure the layout of the logging messages produced by the underlying logging mechanism.

SLF4J does not actually perform the logging, but delegates to other logging systems (log4j, JUL, etc) based on how you set it up.

So if you are binding SLF4J with JUL, then I think the real question you are asking is either one of

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文