SLF4J
This article does not cite any references or sources. Please help improve this article by adding citations to reliable sources. Unsourced material may be challenged and removed. (January 2010) |
Developer(s) | Ceki Gülcü |
---|---|
Stable release | 1.5.10 / December 3, 2009 |
Written in | Java |
Operating system | Cross-platform |
Type | Logging Tool |
License | MIT License |
Website | http://www.slf4j.org/ |
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 deployment time and includes java.util.logging
, log4j and logback.
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 an enhancement over the already-successful log4j framework. It improves on log4j by addressing a few criticisms of log4j relating to performance, as well as providing the facade pattern. SLF4J was also created partly in response to certain criticisms of the Jakarta Commons Logging framework.
Similarities and Differences with Log4j
- Five of Log4j's six logging levels are used. 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.
- 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. Occurrences of the simple pattern {} in the log message is replaced in turn with the values. This is simple to use yet provides a performance benefit when the values have expensive toString() methods. When logging is disabled at the DEBUG level, the logging framework does not need to evaluate the string representation of the values. In the following example, the values count or userAccountList only need to be evaluated when DEBUG is enabled; otherwise the overhead of the debug call is trivial.
LOG.debug("There are now " + count + " user accounts: " + userAccountList); // slow
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 nugatory processing.
- Unlike Log4j, SLF4J offers logging methods that accept markers. These are special objects that enrich the log messages and are an idea that SLF4J has borrowed from logback.
See also
External links
If you like SEOmastering Site, you can support it by - BTC: bc1qppjcl3c2cyjazy6lepmrv3fh6ke9mxs7zpfky0 , TRC20 and more...
- Pages where expansion depth is exceeded
- Pages using deprecated source tags
- Pages with syntax highlighting errors
- Pages with broken file links
- Articles lacking sources from January 2010
- Articles with invalid date parameter in template
- All articles lacking sources
- Java programming language
- Software using the MIT license