Java 禁止所有 Logback 输出到控制台?
声明:本页面是StackOverFlow热门问题的中英对照翻译,遵循CC BY-SA 4.0协议,如果您需要使用它,必须同样遵循CC BY-SA许可,注明原文地址和作者信息,同时你必须将它归于原作者(不是我):StackOverFlow
原文地址: http://stackoverflow.com/questions/3401051/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Suppress all Logback output to console?
提问by Derek Mahar
How can I configure Logback to suppress all of its output to the console (standard output)? In particular, I wish to suppress (or redirect) Logback's own log messages such as the following:
如何配置 Logback 以抑制其所有输出到控制台(标准输出)?特别是,我希望抑制(或重定向)Logback 自己的日志消息,例如:
16:50:25,814 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Could NOT find resource [logback-test.xml]
16:50:25,814 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Found resource [logback.xml] at [file:/opt/dap/domains/ap0491/uat1/domain/instance-config/logback.xml]
16:50:25,816 |-WARN in ch.qos.logback.classic.LoggerContext[default] - Resource [logback.xml] occurs multiple times on the classpath.
16:50:25,816 |-WARN in ch.qos.logback.classic.LoggerContext[default] - Resource [logback.xml] occurs at [file:/opt/dap/domains/ap0491/uat1/domain/instance-config/logback.xml]
16:50:25,816 |-WARN in ch.qos.logback.classic.LoggerContext[default] - Resource [logback.xml] occurs at [file:/opt/dap/domains/ap0491/uat1/domain/instance-config/logback.xml]
16:50:25,923 |-INFO in ch.qos.logback.classic.joran.action.ConfigurationAction - debug attribute not set
16:50:25,924 |-INFO in ch.qos.logback.classic.turbo.ReconfigureOnChangeFilter@1a15291 - Will scan for changes in file [/opt/dap/domains/ap0491/uat1/domain/instance-config/logback.xml] every 60 seconds.
I need to disable all logging to standard output because our production environment disallows applications from printing any messages to standard output.
我需要禁用所有日志记录到标准输出,因为我们的生产环境不允许应用程序将任何消息打印到标准输出。
Note I'm using Logback 0.9.21, SLF4J 1.6.0, and our application runs in WebLogic 10.3.2.
注意我使用的是 Logback 0.9.21、SLF4J 1.6.0,我们的应用程序在 WebLogic 10.3.2 中运行。
采纳答案by Derek Mahar
Holger Hoffst?tte was correct in his diagnosisthat the duplicate classpath entry message is a symptom of a bugin how Logback counts classpath entries. Robert Elliot also characterizedthe problem in a threadon the Logback user mailing list. According to Robert and others in this related disussionon the SLF4J mailing list, when an application that uses Logback runs in a WebLogic container, due to the way the WebLogic classloader operates, Logback reports duplicate classpath entries for the logback.xml
configuration file. However, regardless of whether the WebLogic classloader should or should not report only unique classpath entries, Logback should certainly count only unique classpath entries so that it does not print this confusing, spurious message.
Holger Hoffst?tte 在他的诊断中是正确的,即重复的类路径条目消息是Logback 如何计算类路径条目的错误的症状。Robert Elliot 还在Logback用户邮件列表上的一个线程中描述了这个问题。根据罗伯特和其他人在这个相关disussion的SLF4J邮件列表时使用的logback应用在WebLogic容器中运行,由于在WebLogic类加载器的操作方式上,报告的logback对重复的类路径条目logback.xml
配置文件。然而,无论 WebLogic 类加载器是否应该或不应该只报告唯一的类路径条目,Logback 肯定应该只计算唯一的类路径条目,以便它不会打印这种令人困惑、虚假的消息。
I have implemented a fixfor LBCLASSIC-159that essentially does what Robert Elliot recommends and uses a set instead of a list to hold the resources that the classloader returns, effectively eliminating any duplicate classpath resources. I have successfully tested the fix with Logback 0.9.24, SLF4J 1.6.1, and WebLogic 10.3.2. As Thorbj?rn predicted in his answer, with this fix in place, Logback no longer displays the duplicate classpath entry status messages (or any of the other informational messages) to standard output.
我已经为LBCLASSIC-159实施了一个修复程序,它基本上按照 Robert Elliot 的建议进行操作,并使用集合而不是列表来保存类加载器返回的资源,从而有效地消除了任何重复的类路径资源。我已经使用 Logback 0.9.24、SLF4J 1.6.1 和 WebLogic 10.3.2 成功测试了该修复程序。正如 Thorbj?rn 在他的回答中预测的那样,有了这个修复程序,Logback 不再向标准输出显示重复的类路径条目状态消息(或任何其他信息性消息)。
I hope that the maintainers will integrate my fix into the main Logback source code repositoryand include it in the next release.
我希望维护人员将我的修复程序集成到主 Logback源代码存储库中,并将其包含在下一个版本中。
回答by Brian S
I'm not familiar with Logback. But if it's printing to System.out
or System.err
, these are simply public static PrintStream
variables in the System
class. You could subclass PrintStream
and set the system output variables to your subclass, thus controlling how it works.
我对 Logback 不熟悉。但是如果它打印到System.out
or System.err
,这些只是类中的公共静态PrintStream
变量System
。您可以子类化PrintStream
并将系统输出变量设置为您的子类,从而控制它的工作方式。
For example:
例如:
public class NOPPrintStream extends PrintStream
{
public NOPPrintStream() { super((OutputStream)null); }
public void println(String s) { /* Do nothing */ }
// You may or may not have to override other methods
}
public class MyClass
{
public static void main(String[] args)
{
System.out = new NOPPrintStream();
// Start program
}
}
(This code is untested)
(此代码未经测试)
回答by Thorbj?rn Ravn Andersen
Those messages only show if at least one of the following is true:
这些消息仅在以下至少一项为真时显示:
- you have debugging enabled in the logback.xml file
- you have an error in your configuration. That is the case here - logback complains about multiple configuration files found.
- there is a classpath problem if your environment provides conflicting files. (this one occurred to me yesterday and was the real cause of this question).
- (there is a bug in logback - has happened)
- 您在 logback.xml 文件中启用了调试
- 你的配置有错误。这就是这种情况 - logback 抱怨找到了多个配置文件。
- 如果您的环境提供冲突文件,则存在类路径问题。(这个昨天发生在我身上,是这个问题的真正原因)。
- (logback 中有一个错误 - 发生了)
Correct the issue and those messages should go away.
纠正问题,这些消息应该会消失。
回答by Holger Hoffst?tte
Actually the fact that the same logback.xml location is reported multiple times seems more like a bug in logback than anything else. Either report this to the logback JIRA (here) or first check whether the jar in question is on the classpath multiple times.
实际上,多次报告相同的 logback.xml 位置这一事实似乎更像是 logback 中的错误,而不是其他任何事情。要么将此报告给 logback JIRA(此处),要么首先多次检查有问题的 jar 是否在类路径上。
回答by Michael McCallum
So I had the same problem but found that removing the incorrect <layout /> entry which was deprecated somewhere around 0.9.4 and the messages went away...
所以我遇到了同样的问题,但发现删除了不正确的 <layout /> 条目,该条目在 0.9.4 左右被弃用,消息消失了......
You appender should look some thing like
你的 appender 应该看起来像
<appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender">
<filter class="ch.qos.logback.classic.filter.ThresholdFilter">
<level>info</level>
</filter>
<encoder>
<pattern>%d{yyyy-MM-dd} %d{HH:mm:ss} %.-1level %thread %logger{36}: %m%n</pattern>
</encoder>
</appender>
I've blogged about a more completedescription of what I changed that worked for me
我在博客中更完整地描述了对我有用的更改
回答by Carl Smotricz
This is a "me too" answer, sorry!
这是一个“我也是”的答案,对不起!
Happily, I've found a solution (see UPDATE) below.
令人高兴的是,我在下面找到了一个解决方案(请参阅更新)。
Contrary to some of the other answers, I'm getting a stream of LogBack configuration INFO
messages in spite of having no ERROR
s or WARN
s in the configuration phase.
与其他一些答案相反INFO
,尽管在配置阶段没有ERROR
s 或WARN
s ,我还是收到了 LogBack 配置消息流。
Here are my messages:
以下是我的留言:
13:39:20,457 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Could NOT find resource [logback.groovy]
13:39:20,457 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Could NOT find resource [logback-test.xml]
13:39:20,457 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Found resource [logback.xml] at [file:/home/carl/workspace-LSY/.metadata/.plugins/org.eclipse.wst.server.core/tmp0/wtpwebapps/IceProfile/WEB-INF/classes/logback.xml]
13:39:20,496 |-INFO in ch.qos.logback.classic.turbo.ReconfigureOnChangeFilter@14e2c9c - Will scan for changes in file [/home/carl/workspace-LSY/.metadata/.plugins/org.eclipse.wst.server.core/tmp0/wtpwebapps/IceProfile/WEB-INF/classes/logback.xml] every 60 seconds.
13:39:20,496 |-INFO in ch.qos.logback.classic.joran.action.ConfigurationAction - Adding ReconfigureOnChangeFilter as a turbo filter
13:39:20,497 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - About to instantiate appender of type [ch.qos.logback.core.ConsoleAppender]
13:39:20,501 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - Naming appender as [STDOUT]
13:39:20,510 |-INFO in ch.qos.logback.core.joran.action.NestedComplexPropertyIA - Assuming default type [ch.qos.logback.classic.encoder.PatternLayoutEncoder] for [encoder] property
13:39:20,510 |-INFO in ch.qos.logback.core.joran.action.NestedComplexPropertyIA - Pushing component [encoder] on top of the object stack.
13:39:20,537 |-INFO in ch.qos.logback.classic.joran.action.RootLoggerAction - Setting level of ROOT logger to DEBUG
13:39:20,537 |-INFO in ch.qos.logback.core.joran.action.AppenderRefAction - Attaching appender named [STDOUT] to Logger[ROOT]
13:39:20,538 |-INFO in ch.qos.logback.classic.joran.action.LoggerAction - Setting level of logger [ch.qos.logback] to OFF
13:39:20,538 |-INFO in ch.qos.logback.classic.joran.action.LoggerAction - Setting additivity of logger [ch.qos.logback] to false
13:39:20,538 |-INFO in ch.qos.logback.classic.joran.action.ConfigurationAction - End of configuration.
Here's my configuration:
这是我的配置:
<configuration debug="true" scan="true">
<appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
<!-- encoders are by default assigned the type
ch.qos.logback.classic.encoder.PatternLayoutEncoder -->
<encoder>
<pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n</pattern>
</encoder>
</appender>
<root level="debug">
<appender-ref ref="STDOUT" />
</root>
<logger name="ch.qos.logback" level="OFF" additivity="false" />
</configuration>
This is spam I don't want, I consider myself innocent of having provoked it, and I'd appreciate some help in getting rid of it.
这是我不想要的垃圾邮件,我认为自己没有挑起它,如果能帮助我摆脱它,我将不胜感激。
One respect in which I may be "guilty" is that I'm initializing my loggers in a static
variable; the docs recommend using instance variables instead.
我可能“有罪”的一个方面是我在一个static
变量中初始化我的记录器;文档建议改用实例变量。
Versions:
版本:
- logback-classic-0.9.24.jar
- logback-core-0.9.24.jar
- slf4j-api-1.6.1.jar
- executing in an IceFaces 2.0 app running in Tomcat 6.0 under Ubuntu 11.04
- logback-classic-0.9.24.jar
- logback-core-0.9.24.jar
- slf4j-api-1.6.1.jar
- 在 Ubuntu 11.04 下的 Tomcat 6.0 中运行的 IceFaces 2.0 应用程序中执行
UPDATE
更新
Finally figured out what the problem was!
终于知道是什么问题了!
From the fine manual(and Thorbj?rn's answer):
来自精美的手册(和Thorbj?rn 的回答):
Setting the debug attributewithin the element will output status information, under the assumption that
- the configuration file is found
- the configuration file is well-formed XML.
在元素中设置 debug 属性将输出状态信息,假设
- 找到配置文件
- 配置文件是格式良好的 XML。
My mistake was
我的错误是
<configuration debug="true" scan="true">
In retrospect, duh!Hopefully this information will help others.
回想起来,呵呵!希望这些信息能帮助其他人。
回答by baja
You most likely have a element configured in your logback.xml. You can remove it, if you don't want any console updates about the state of the logging framework itself. Though, logback framework recommends against disabling it for troubleshooting purposes.
您很可能在 logback.xml 中配置了一个元素。如果您不希望任何关于日志框架本身状态的控制台更新,您可以删除它。不过,logback 框架建议不要出于故障排除目的禁用它。
There is an alternative to the console listener called StatusListenerAsList which keeps the status messages as a private list. You can expose it via JMX, if needed, with a little bit of code.
有一个名为 StatusListenerAsList 的控制台侦听器的替代方法,它将状态消息保留为私有列表。如果需要,您可以使用少量代码通过 JMX 公开它。
回答by Betlista
I just want to add information about default header message added in logback 1.0.2:
我只想添加有关在 logback 1.0.2 中添加的默认标头消息的信息:
#logback.classic pattern: %d [%thread] %-5level %logger{36} - %msg%n
I found that in logback news, but it was really difficult to find.
我在logback news 中找到了,但真的很难找到。
If you wish to remove this message, you have to set up outputPatternAsPresentationHeader
to false:
如果要删除此消息,则必须设置outputPatternAsPresentationHeader
为 false:
<appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
<encoder>
<pattern>%d %-5level [%thread] %logger{0}: %msg%n</pattern>
<!-- do not print pattern as a header -->
<outputPatternAsPresentationHeader>false</outputPatternAsPresentationHeader>
</encoder>
</appender>
回答by xtian
In my case, I had the "logback-test.xml" in a dependent project that was being deployed as a webapp jar. The "logback-test.xml" file started with
就我而言,我在一个被部署为 webapp jar 的依赖项目中有“logback-test.xml”。“logback-test.xml”文件以
<configuration debug="false" scan="true">
The 'scan="true"' attribute generated this error:
'scan="true"' 属性产生了这个错误:
ERROR in ch.qos.logback.classic.turbo.ReconfigureOnChangeFilter@716de067 - URL [jar:file:/C:/Local...cut.../WEB-INF/lib/My.Dev.jar!/logback-test.xml] is not of type file
which resulted in 67 (!) more INFO lines.
这导致了 67 (!) 更多 INFO 行。
By removing the 'scan="true"' attribute, the logback log disappeared altogether.
通过删除 'scan="true"' 属性,logback 日志完全消失了。
回答by Rupesh Kumar
<configuration>
<statusListener class="ch.qos.logback.core.status.NopStatusListener" />
</configuration>
Simplely use NopStatusLinstener class and this will stop self logging of logback.
简单地使用 NopStatusLinstener 类,这将停止 logback 的自我记录。