SLF4J: Difference between revisions
Content deleted Content added
m Wikidata for logo; slf4j->SLF4J |
|||
| Line 29: | Line 29: | ||
private static final Logger LOG = LoggerFactory.getLogger(Wombat.class); |
private static final Logger LOG = LoggerFactory.getLogger(Wombat.class); |
||
</source> |
</source> |
||
*In ''Logger'', the logging methods are [[Function overloading|overloaded]] with forms that accept one, two or more values.<ref>[https://slf4j.org/apidocs/org/slf4j/Logger.html SLF4J api docs: Logger]</ref> Occurrences of the simple pattern <code>{}</code> in the log message are replaced in turn with the values. This is simple to use yet provides a performance benefit when the values have expensive <code>toString()</code> methods. When logging is disabled at the |
*In ''Logger'', the logging methods are [[Function overloading|overloaded]] with forms that accept one, two or more values.<ref>[https://slf4j.org/apidocs/org/slf4j/Logger.html SLF4J api docs: Logger]</ref> Occurrences of the simple pattern <code>{}</code> in the log message are replaced in turn with the values. This is simple to use yet provides a performance benefit when the values have expensive <code>toString()</code> methods. When logging is disabled at the given level, the logging framework does not need to evaluate the string representation of the values, or construct a log message string that is never actually logged. In the following example, string concatenation and <code>toString()</code> method for the values <code>count</code> or <code>userAccountList</code> are performed only when DEBUG is enabled. |
||
<source lang="java"> |
|||
LOG.debug("There are now " + count + " user accounts: " + userAccountList); // |
LOG.debug("There are now " + count + " user accounts: " + userAccountList); // slower |
||
LOG.debug("There are now {} user accounts: {}", count, userAccountList); // faster |
LOG.debug("There are now {} user accounts: {}", count, userAccountList); // faster |
||
</source> |
</source> |
||
Revision as of 23:33, 2 May 2018
 |
 | |
| Developer(s) | Ceki Gülcü |
|---|---|
| Stable release | 1.7.25[1]
/ March 16, 2017 |
| Repository | |
| Written in | Java |
| Operating system | Cross-platform |
| Type | Logging Tool |
| License | MIT License |
| Website | www |
Simple Logging Facade for Java (SLF4J) provides a Java logging API by means of a simple facade pattern. The underlying logging backend is determined at runtime by adding the desired binding to the classpath and may be the standard Sun Java logging package java.util.logging,[2] log4j, logback[3] or tinylog.[4][5]
The separation of the client API from the logging backend reduces the coupling between an application and any particular logging framework. This can make it easier to integrate with existing or third-party code or to deliver code into other projects that have already made a choice of logging backend.
SLF4J was created by Ceki Gülcü as a more reliable alternative to Jakarta Commons Logging framework.[6][7] Research in 2013 on 10,000 GitHub projects found that the most popular Java library is SLF4J, with 30.7% of projects using it.[8]
Similarities and differences with log4j 1.x
- Five of log4j's six logging levels are used (ERROR, WARN, INFO, DEBUG, TRACE). FATAL has been dropped on the basis that inside the logging framework is not the place to decide when an application should terminate and therefore there is no difference between ERROR and FATAL from the logger's point of view. In addition, SLF4J markers offer a more general method for tagging log statements. For example, any log statement of level ERROR can be tagged with the "FATAL" marker.
- Logger instances are created via the
LoggerFactory, which is very similar in log4j. For example,private static final Logger LOG = LoggerFactory.getLogger(Wombat.class);
- In Logger, the logging methods are overloaded with forms that accept one, two or more values.[9] Occurrences of the simple pattern
{}in the log message are replaced in turn with the values. This is simple to use yet provides a performance benefit when the values have expensivetoString()methods. When logging is disabled at the given level, the logging framework does not need to evaluate the string representation of the values, or construct a log message string that is never actually logged. In the following example, string concatenation andtoString()method for the valuescountoruserAccountListare performed only when DEBUG is enabled.
LOG.debug("There are now " + count + " user accounts: " + userAccountList); // slower
LOG.debug("There are now {} user accounts: {}", count, userAccountList); // faster
- Similar methods exist in Logger for
isDebugEnabled()etc. to allow more complex logging calls to be wrapped so that they are disabled when the corresponding level is disabled, avoiding unnecessary processing. - Unlike log4j, SLF4J offers logging methods that accept markers. These are special objects that enrich the log messages. At present time, logback is the only framework which makes use of markers.
Similarities and differences with log4j 2.x
Apache log4j 2.x supports all slf4j features.[10]
See also
References
- ^ "SLF4J News". slfj4.org. 2017-11-28.
- ^ java.util.logging
- ^ logback
- ^ tinylog
- ^ SLF4J binding for tinylog
- ^ "Think again before adopting the commons-logging API"
- ^ "Taxonomy of class loader problems encountered when using Jakarta Commons Logging"
- ^ "We Analyzed 30,000 GitHub Projects – Here Are The Top 100 Libraries in Java, JS and Ruby".
- ^ SLF4J api docs: Logger
- ^ Apache log4j 2.x slf4j Binding