fbpx
Wikipedia

Java logging framework

January 01, 1970

A Java logging framework is a computer data logging package for the Java platform. This article covers general purpose logging frameworks.

Logging refers to the recording of activity by an application and is a common issue for development teams. Logging frameworks ease and standardize the process of logging for the Java platform. In particular they provide flexibility by avoiding explicit output to the console (see Appender below). Where logs are written becomes independent of the code and can be customized at runtime.

Unfortunately the JDK did not include logging in its original release so by the time the Java Logging API was added several other logging frameworks had become widely used – in particular Apache Commons Logging (also known as Java Commons Logging or JCL) and Log4j. This led to problems when integrating different third-party libraries (JARs) each using different logging frameworks. Pluggable logging frameworks (wrappers) were developed to solve this problem.

Functionality overview edit

Logging is typically broken into three major pieces: the Logger, the Formatter and the Appender (or Handler).

  • The Logger is responsible for capturing the message to be logged along with certain metadata and passing it to the logging framework.
  • After receiving the message, the framework calls the Formatter with the message which formats it for output.
  • The framework then hands the formatted message to the appropriate Appender/Handler for disposition. This might include output to a console display, writing to disk, appending to a database, or generating an email.

Simpler logging frameworks, like Logging Framework by the Object Guy, combine the logger and the appender. This simplifies default operation, but it is less configurable, especially if the project is moved across environments.

Logger edit

A Logger is an object that allows the application to log without regard to where the output is sent/stored. The application logs a message by passing an object or an object and an exception with an optional severity level to the logger object under a given name/identifier.

Name edit

A logger has a name. The name is usually structured hierarchically, with periods (.) separating the levels. A common scheme is to use the name of the class or package that is doing the logging. Both Log4j and the Java logging API support defining handlers higher up the hierarchy.

For example, the logger might be named "com.sun.some.UsefulClass". The handler can be defined for any of the following:

  • com
  • com.sun
  • com.sun.some
  • com.sun.some.UsefulClass

As long as there is a handler defined somewhere in this stack, logging may occur. For example a message logged to the com.sun.some.UsefulClass logger, may get written by the com.sun handler. Typically there is a global handler that receives and processes messages generated by any logger.

Severity level edit

The message is logged at a certain level. Common level names are copied from Apache Commons Logging (although the Java Logging API defines different level names):

Common levels
Level Description
FATAL Severe errors that cause premature termination. Expect these to be immediately visible on a status console.
ERROR Other runtime errors or unexpected conditions. Expect these to be immediately visible on a status console.
WARNING Use of deprecated APIs, poor use of API, 'almost' errors, other runtime situations that are undesirable or unexpected, but not necessarily "wrong". Expect these to be immediately visible on a status console.
INFO Interesting runtime events (startup/shutdown). Expect these to be immediately visible on a console, so be conservative and keep to a minimum.
DEBUG detailed information on the flow through the system. Expect these to be written to logs only.
TRACE more detailed information. Expect these to be written to logs only.

The logging framework maintains the current logging level for each logger. The logging level can be set more or less restrictive. For example, if the logging level is set to "WARNING", then all messages of that level or higher are logged: ERROR and FATAL.

Severity levels can be assigned to both loggers and appenders. Both must be enabled for a given severity level for output to be generated. So a logger enabled for debug output will not generate output if the handler that gets the message is not also enabled for debug.

Filters edit

Filters cause a log event to be ignored or logged. The most commonly used filter is the logging level documented in the previous section. Logging frameworks such as Log4j 2 and SLF4J also provide Markers, which when attached to a log event can also be used for filtering. Filters can also be used to accept or deny log events based on exceptions being thrown, data within the log message, data in a ThreadLocal that is exposed through the logging API, or a variety of other methods.

Formatters, Layouts or renderers edit

A Formatter is an object that formats a given object. Mostly this consists of taking the binary object and converting it to a string representation. Each framework defines a default output format that can be overridden if desired.

Appenders or handlers edit

Appenders listen for messages at or above a specified minimum severity level. The Appender takes the message it is passed and posts it appropriately. Message dispositions include:

  • display on the console
  • write to a file or syslog
  • append to a database table
  • distribute via Java Messaging Services
  • send via email
  • write to a socket
  • discard to the "bit-bucket" (/dev/null)

Feature comparison edit

Table 1 - Features
Framework Type Supported Log Levels Standard Appenders Comments Cost / Licence
Log4j Logging Framework FATAL ERROR WARN INFO DEBUG TRACE Too many to list: See Appender Documentation Widely used in many projects and platforms. Log4j 1 was declared "End of Life" in 2015 and has been replaced with Log4j 2 which provides an API that can be used with other logging implementations as well as an implementation of that API.
Apache License, Version 2.0
Java Logging API Logging Framework SEVERE WARNING INFO CONFIG FINE FINER FINEST Sun's default Java Virtual Machine (JVM) has the following: ConsoleHandler, FileHandler, SocketHandler, MemoryHandler Comes with the JRE
tinylog Logging Framework ERROR WARNING INFO DEBUG TRACE ConsoleWriter, FileWriter, LogcatWriter, JdbcWriter, RollingFileWriter, SharedFileWriter and null (discards all log entries) [1] Apache License, Version 2.0
Logback Logging Framework ERROR WARN INFO DEBUG TRACE Too many to list: see Appender JavaDoc Developed as a replacement for Log4j, with many improvements. Used by numerous projects, typically behind slf4j, for example Akka, Apache Camel, Apache Cocoon, Artifactory, Gradle, Lift Framework, Play Framework, Scalatra, SonarQube, Spring Boot, ... LGPL, Version 2.1
Apache Commons Logging (JCL) Logging Wrapper FATAL ERROR WARN INFO DEBUG TRACE Depends on the underlying framework Widely used, often in conjunction with Log4j Apache License, Version 2.0
SLF4J Logging Wrapper ERROR WARN INFO DEBUG TRACE Depends on the underlying framework, which is pluggable. Provides API compatible shims for JCL, JDK and Log4j logging packages. It can also use any of them to generate output. Defaults to using Logback for output if available. Widely used in many projects and platforms, frequently with Logback as the implementation. MIT License

Considerations edit

JCL and Log4j are very common simply because they have been around for so long and were the only choices for a long time. The flexibility of slf4j (using Logback underneath) has made it a popular choice.

SLF4J is a set of logging wrappers (or shims) that allow it to imitate any of the other frameworks. Thus multiple third-party libraries can be incorporated into an application, regardless of the logging framework each has chosen to use. However all logging output is generated in a standard way, typically via Logback.

Log4j 2 provides both an API and an implementation. The API can be routed to other logging implementations equivalent to how SLF4J works. Unlike SLF4J, the Log4j 2 API logs Message[2] objects instead of Strings for extra flexibility and also supports Java Lambda expressions.[3]

JCL isn't really a logging framework, but a wrapper for one. As such, it requires a logging framework underneath it, although it can default to using its own SimpleLog logger.

JCL, SLF4J and the Log4j 2 API are useful when developing reusable libraries which need to write to whichever underlying logging system is being used by the application. This also provides flexibility in heterogeneous environments where the logging framework is likely to change, although in most cases, once a logging framework has been chosen, there is little need to change it over the life of the project. SLF4J and Log4j 2 benefit from being newer and build on the lessons learned from older frameworks. Moreover JCL has known problems with class-loaders when determining what logging library it should wrap [4] which has now replaced JCL.[5]

The Java Logging API is provided with Java. Although the API is technically separate from the default implementation provided with Java, replacing it with an alternate implementation can be challenging so many developers confuse this implementation with the Java Logging API. Configuration is by external files only which is not easily changed on the fly (other frameworks support programmatic configuration). The default implementation only provides a few Handlers and Formatters which means most users will have to write their own.[6]

See also edit

References edit

  1. ^ "User manual of tinylog". Archived from the original on April 15, 2013.
  2. ^ Log4j2 API Messages
  3. ^ Java 8 Lambda support for lazy logging
  4. ^ Avoiding Commons Logging
  5. ^ Spring Logging Overview
  6. ^ java.util.logging Overview

External links edit

  • Java 6.0 Logging API
  • Commons Logging
  • Protomatter
  • Open Source Logging Tools in Java
  • The Apache 2.0 license.
  • Logback - A successor to the popular Log4j project
  • tinylog - Minimalist logging utility with a static logger
  • Loggifier A tool that inserts logging code into .class, .jar and .ear files
  • JLV - Java logging viewer which is currently available as a plugin for Eclipse IDE
  • Perf4j
  • SLF4J
  • Log4j 2

January 01, 1970
java, logging, framework, this, article, multiple, issues, please, help, improve, discuss, these, issues, talk, page, learn, when, remove, these, template, messages, this, article, needs, additional, citations, verification, please, help, improve, this, articl. This article has multiple issues Please help improve it or discuss these issues on the talk page Learn how and when to remove these template messages This article needs additional citations for verification Please help improve this article by adding citations to reliable sources Unsourced material may be challenged and removed Find sources Java logging framework news newspapers books scholar JSTOR June 2008 Learn how and when to remove this message This article possibly contains original research Please improve it by verifying the claims made and adding inline citations Statements consisting only of original research should be removed June 2008 Learn how and when to remove this message Learn how and when to remove this message A Java logging framework is a computer data logging package for the Java platform This article covers general purpose logging frameworks Logging refers to the recording of activity by an application and is a common issue for development teams Logging frameworks ease and standardize the process of logging for the Java platform In particular they provide flexibility by avoiding explicit output to the console see Appender below Where logs are written becomes independent of the code and can be customized at runtime Unfortunately the JDK did not include logging in its original release so by the time the Java Logging API was added several other logging frameworks had become widely used in particular Apache Commons Logging also known as Java Commons Logging or JCL and Log4j This led to problems when integrating different third party libraries JARs each using different logging frameworks Pluggable logging frameworks wrappers were developed to solve this problem Contents 1 Functionality overview 1 1 Logger 1 1 1 Name 1 1 2 Severity level 1 2 Filters 1 3 Formatters Layouts or renderers 1 4 Appenders or handlers 1 5 Feature comparison 2 Considerations 3 See also 4 References 5 External linksFunctionality overview editLogging is typically broken into three major pieces the Logger the Formatter and the Appender or Handler The Logger is responsible for capturing the message to be logged along with certain metadata and passing it to the logging framework After receiving the message the framework calls the Formatter with the message which formats it for output The framework then hands the formatted message to the appropriate Appender Handler for disposition This might include output to a console display writing to disk appending to a database or generating an email Simpler logging frameworks like Logging Framework by the Object Guy combine the logger and the appender This simplifies default operation but it is less configurable especially if the project is moved across environments Logger edit A Logger is an object that allows the application to log without regard to where the output is sent stored The application logs a message by passing an object or an object and an exception with an optional severity level to the logger object under a given name identifier Name edit A logger has a name The name is usually structured hierarchically with periods separating the levels A common scheme is to use the name of the class or package that is doing the logging Both Log4j and the Java logging API support defining handlers higher up the hierarchy For example the logger might be named com sun some UsefulClass The handler can be defined for any of the following com com sun com sun some com sun some UsefulClass As long as there is a handler defined somewhere in this stack logging may occur For example a message logged to the com sun some UsefulClass logger may get written by the com sun handler Typically there is a global handler that receives and processes messages generated by any logger Severity level edit The message is logged at a certain level Common level names are copied from Apache Commons Logging although the Java Logging API defines different level names Common levels Level Description FATAL Severe errors that cause premature termination Expect these to be immediately visible on a status console ERROR Other runtime errors or unexpected conditions Expect these to be immediately visible on a status console WARNING Use of deprecated APIs poor use of API almost errors other runtime situations that are undesirable or unexpected but not necessarily wrong Expect these to be immediately visible on a status console INFO Interesting runtime events startup shutdown Expect these to be immediately visible on a console so be conservative and keep to a minimum DEBUG detailed information on the flow through the system Expect these to be written to logs only TRACE more detailed information Expect these to be written to logs only The logging framework maintains the current logging level for each logger The logging level can be set more or less restrictive For example if the logging level is set to WARNING then all messages of that level or higher are logged ERROR and FATAL Severity levels can be assigned to both loggers and appenders Both must be enabled for a given severity level for output to be generated So a logger enabled for debug output will not generate output if the handler that gets the message is not also enabled for debug Filters edit Filters cause a log event to be ignored or logged The most commonly used filter is the logging level documented in the previous section Logging frameworks such as Log4j 2 and SLF4J also provide Markers which when attached to a log event can also be used for filtering Filters can also be used to accept or deny log events based on exceptions being thrown data within the log message data in a ThreadLocal that is exposed through the logging API or a variety of other methods Formatters Layouts or renderers edit A Formatter is an object that formats a given object Mostly this consists of taking the binary object and converting it to a string representation Each framework defines a default output format that can be overridden if desired Appenders or handlers edit Appenders listen for messages at or above a specified minimum severity level The Appender takes the message it is passed and posts it appropriately Message dispositions include display on the console write to a file or syslog append to a database table distribute via Java Messaging Services send via email write to a socket discard to the bit bucket dev null Feature comparison edit Table 1 Features Framework Type Supported Log Levels Standard Appenders Comments Cost Licence Log4j Logging Framework FATAL ERROR WARN INFO DEBUG TRACE Too many to list See Appender Documentation Widely used in many projects and platforms Log4j 1 was declared End of Life in 2015 and has been replaced with Log4j 2 which provides an API that can be used with other logging implementations as well as an implementation of that API Apache License Version 2 0 Java Logging API Logging Framework SEVERE WARNING INFO CONFIG FINE FINER FINEST Sun s default Java Virtual Machine JVM has the following ConsoleHandler FileHandler SocketHandler MemoryHandler Comes with the JRE tinylog Logging Framework ERROR WARNING INFO DEBUG TRACE ConsoleWriter FileWriter LogcatWriter JdbcWriter RollingFileWriter SharedFileWriter and null discards all log entries 1 Apache License Version 2 0 Logback Logging Framework ERROR WARN INFO DEBUG TRACE Too many to list see Appender JavaDoc Developed as a replacement for Log4j with many improvements Used by numerous projects typically behind slf4j for example Akka Apache Camel Apache Cocoon Artifactory Gradle Lift Framework Play Framework Scalatra SonarQube Spring Boot LGPL Version 2 1 Apache Commons Logging JCL Logging Wrapper FATAL ERROR WARN INFO DEBUG TRACE Depends on the underlying framework Widely used often in conjunction with Log4j Apache License Version 2 0 SLF4J Logging Wrapper ERROR WARN INFO DEBUG TRACE Depends on the underlying framework which is pluggable Provides API compatible shims for JCL JDK and Log4j logging packages It can also use any of them to generate output Defaults to using Logback for output if available Widely used in many projects and platforms frequently with Logback as the implementation MIT LicenseConsiderations editJCL and Log4j are very common simply because they have been around for so long and were the only choices for a long time The flexibility of slf4j using Logback underneath has made it a popular choice SLF4J is a set of logging wrappers or shims that allow it to imitate any of the other frameworks Thus multiple third party libraries can be incorporated into an application regardless of the logging framework each has chosen to use However all logging output is generated in a standard way typically via Logback Log4j 2 provides both an API and an implementation The API can be routed to other logging implementations equivalent to how SLF4J works Unlike SLF4J the Log4j 2 API logs Message 2 objects instead of Strings for extra flexibility and also supports Java Lambda expressions 3 JCL isn t really a logging framework but a wrapper for one As such it requires a logging framework underneath it although it can default to using its own SimpleLog logger JCL SLF4J and the Log4j 2 API are useful when developing reusable libraries which need to write to whichever underlying logging system is being used by the application This also provides flexibility in heterogeneous environments where the logging framework is likely to change although in most cases once a logging framework has been chosen there is little need to change it over the life of the project SLF4J and Log4j 2 benefit from being newer and build on the lessons learned from older frameworks Moreover JCL has known problems with class loaders when determining what logging library it should wrap 4 which has now replaced JCL 5 The Java Logging API is provided with Java Although the API is technically separate from the default implementation provided with Java replacing it with an alternate implementation can be challenging so many developers confuse this implementation with the Java Logging API Configuration is by external files only which is not easily changed on the fly other frameworks support programmatic configuration The default implementation only provides a few Handlers and Formatters which means most users will have to write their own 6 See also editSLF4J Log4j logback Javolution LogContext based on context programming actual logging framework selectable at run time Runtime intelligenceReferences edit User manual of tinylog Archived from the original on April 15 2013 Log4j2 API Messages Java 8 Lambda support for lazy logging Avoiding Commons Logging Spring Logging Overview java util logging OverviewExternal links editJava 6 0 Logging API Commons Logging Protomatter Open Source Logging Tools in Java The Apache 2 0 license Logback A successor to the popular Log4j project tinylog Minimalist logging utility with a static logger Loggifier A tool that inserts logging code into class jar and ear files JLV Java logging viewer which is currently available as a plugin for Eclipse IDE Perf4j SLF4J Log4j 2 Retrieved from https en wikipedia org w index php title Java logging framework amp oldid 1154376380, wikipedia, wiki, book, books, library,

article

, read, download, free, free download, mp3, video, mp4, 3gp, jpg, jpeg, gif, png, picture, music, song, movie, book, game, games.