Sparkles

that were shone when I got tempered!

Log4j Basics

leave a comment »

Log4j is written java and distributed under Apache Software License.

Althogh it is written in Java it is provided for many other languages such as C, C++, C#, Perl, Python, Ruby, and Eiffel.

There are three main components in log4j.

  1. Loggers : captures the logging information.
  2. Appenders : publishes the logging information to various destinations (File, UNIX-SYS logs, DataBases, Network, Console etc).
  3. Layouts : Formats logging information in different styles.

The latest log4j version can be found at http://logging.apache.org/log4j/ with full-source code, class files, and documentation.

Supportive packages may need to log4j works.

  • Java Mail API: E-mail based logging feature in log4j requires this. This is packaged inside the mail.jar. You can take it from here [https://glassfish.dev.java.net/javaee5/mail/]
  • JavaBeans Activation Framework: The Java Mail API will also require that the JavaBeans Activation Framework. This is packaged inside the activation.jar. You can take it from here [http://java.sun.com/products/javabeans/jaf/index.jsp]
  • Java Message Service: The JMS-compatible features of log4j will require that both JMS and Java Naming and Directory Interface JNDI. You can take it from here [http://java.sun.com/products/jms].
  • XML Parser: JAXP-compatible XML parser is also needed to use log4j. This is packaged inside the Xerces.jar. You can take it from here [http://xerces.apache.org/xerces-j/install.html].

To use log4j, you will need to setup the PATH and CLAASPATH variables properly

	$ pwd /usr/local/apache-log4j-1.2.15
	$ export CLASSPATH=$CLASSPATH:/usr/local/apache-log4j-1.2.15/log4j-1.2.15.jar
	$ export PATH=$PATH:/usr/local/apache-log4j-1.2.15/
	

Architecture
Log4j API follows a Layered Architecture. Layered Architecture’s each layer provides different objects to perform different tasks.

There are two types of objects in log4j framework.

  1. Core Objects
  2. Support Objects

Core Objects

These objects represents the three main components in the Log4j Framework.

  1. Logger Object – (top-level)
  2. Layout Object – (middle-level)
  3. Appender Object – (bottom-level)

Layout Object – (middle-level)

The top-level class in the hierarchy is the abstract class org.apache.log4j.Layout.
This class provides a skeleton implementation of all the common operations across all other Layout objects and declares two abstract methods.

1. public abstract boolean ignoresThrowable()
It indicates whether the logging information handles any java.lang.Throwable object passed to it as a part of the logging event. If the Layout object handles the Throwable object, then the Layout object does not ignore it, and returns false.

2. public abstract String format(LoggingEvent event)
Individual layout subclasses implement this method for layout specific formatting.

Apart from these abstract methods, the Layout class provides concrete implementation for the methods listed below:
1. public String getContentType()
It returns the content type used by the Layout objects. The base class returns text/plain as the default content type.

2. public String getFooter()
It specifies the footer information of the logging message.

3. public String getHeader() –
It specifies the header information of the logging message.

This is Sub-classed as follows giving opportunity to format the logging information in different ways.

  • DateLayout
  • HTMLLayout
  • PatternLayout
  • SimpleLayout
  • XMLLayout

Each subclass can return class-specific information by overriding the concrete implementation of the above described methods.

So, all Layout objects receive a LoggingEvent object from the Appender objects. The Layout objects then retrieve the message argument from the LoggingEvent and apply the appropriate ObjectRenderer to obtain the String representation of the message.
It is also possible to create a Layout object that formats logging data in an application-specific way.

Appender Object – (bottom-level)

There are various Appenders in log4j.

  • AppenderSkeleton
  • AsyncAppender
  • ConsoleAppender
  • DailyRollingFileAppender
  • ExternallyRolledFileAppender
  • FileAppender
  • JDBCAppender
  • JMSAppender
  • LF5Appender
  • NTEventLogAppender
  • NullAppender
  • RollingFileAppender
  • SMTPAppender
  • SocketAppender
  • SocketHubAppender
  • SyslogAppender
  • TelnetAppender
  • WriterAppender

Each Appender object has different properties.

  • layout – Appender uses the Layout objects and the conversion pattern to format the logging information
  • target – The target may be a console, a file, or another item depending on the appender
  • level – This is required to control the filtration of the log messages.
  • threshold – Appender ignores any logging messages that have a level lower than the threshold level.
  • filter – This analyzes the logging information beyond level matching and decide whether logging requests should be handled by a particular Appender or ignored.

Support Objects

Level Objects
Level object defines the granularity and priority of the logging information. There are Seven Levels of logging.

  • OFF
  • DEBUG
  • INFO
  • ERROR
  • WARN
  • FATAL
  • ALL.

Filter Objects
Filter Objects analyzes the logging information and make further decisions on whether it should be logged or not.

An Appender object can have multiple Filter objects associated with it. When a logging information is passed to a particular Appender object, all the Filter objects associated with that Appender need to approve the logging information to be published

ObjectRenderer
The ObjectRenderer object is specialized in providing a String representation for an objects passed to the logging framework. This object is used by the Layout objects to prepare the final logging information.

LogManager
The LogManager object is responsible to manage the logging framework. It reads the initial configuration parameters from a system-wide configuration file or a configuration class and manages the framework

How you can configure the core components using a configuration file.
This involves assigning the Level, defining Appender, and specifying Layout objects in a configuration file.

This configuration file is named as log4j.properties. It keeps the properties in key-value pairs. By default, the LogManager looks for a file named log4j.properties in the CLASSPATH when initialze the logging framework.

Example :

Following is the syntax of log4j.properties file for an appender X:

	# Define the root logger with appender X
	log4j.rootLogger = DEBUG, X

	# Set the appender named X to be a File appender
	log4j.appender.X=org.apache.log4j.FileAppender
	log4j.appender.X.File=${log}/log.out

	# Define the layout for X appender
	log4j.appender.X.layout=org.apache.log4j.PatternLayout
	log4j.appender.X.layout.conversionPattern=%m%n
	

In this example,
The level of the root logger is defined as DEBUG. The DEBUG attaches the appender named X to it.
Set a valid appender(FileAppender) to the appender X. It writes the loggin informaion to a file named log.out located in the log directory (log directory path is given as a System Property like ${variableName}).

You can add the appender to the logger inside the program itself using the below provided method.

	public void addAppender(Appender appender);
	

Set the layout (PatternLayout) for the appender X.

This Pattern Layout is given a specified conversionPattern denoted by the TTCC format.

TTCC

TTCC is a message format used by log4j.[6] TTCC is an acronym for Time Thread Category Component. It uses the following pattern:

  • %r  – Used to output the number of milliseconds elapsed from the construction of the layout until the creation of the logging event.
  • %t  – Used to output the name of the thread that generated the logging event.
  • %p – Used to output the priority of the logging event.
  • %c – Used to output the category of the logging event.
  • %x – Used to output the NDC (nested diagnostic context) associated with the thread that generated the logging event.[7]
  • %X{key} – Used to output the MDC (mapped diagnostic context) associated with the thread that generated the logging event for specified key.[8]
  • %m – Used to output the application supplied message associated with the logging event.
  • %n – Used to output the platform-specific newline character or characters.

Initializing Logger.
The Logger class does not allow us to instantiate a new Logger instance. But it provides number of static methods to obtain a Logger object.

Logging Methods
Once the Logger is instantiated, we can use several methods of the logger to log messages.

  1. public void debug(Object message) – Prints messages with the level Level.DEBUG.
  2. public void error(Object message) – Prints messages with the level Level.ERROR.
  3. public void fatal(Object message) – Prints messages with the level Level.FATAL.
  4. public void info(Object message) – Prints messages with the level Level.INFO.
  5. public void warn(Object message) – Prints messages with the level Level.WARN.
  6. public void trace(Object message) – Prints messages with the level Level.TRACE.

Logging Levels.
Log4j is defined the loggin levels in org.apache.log4j.Level. You can also define your custom levels by sub-classing the Level class. This is described more in above Logger Object.

Level Description

  • OFF – The highest possible rank and is intended to turn off logging.
  • FATAL – Severe errors that cause premature termination. Expect these to be immediately visible on a status console.
  • ERROR – Other runtime errors or unexpected conditions that might still allow the application to continue running. Expect these to be immediately visible on a status console.
  • WARN – Use of deprecated APIs, poor use of API, ‘almost’ errors, potentially harmful situations, 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 – Most detailed information. Expect these to be written to logs only. Since version 1.2.12.[5]

If the logger level of the request is lRq and
the level of logger is lLgr,
information will be logged only if lLgr >= lRq.

In this case levels are ordered as ALL < DEBUG < INFO < WARN < ERROR < FATAL < OFF.


Reference : 

Advertisements

Written by Namal Fernando

April 14, 2015 at 9:59 am

Posted in Java, log4j

Tagged with , ,

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Ruth's Reflections

Contemplations from quakey quirky Christchurch

TED Blog

The TED Blog shares interesting news about TED, TED Talks video, the TED Prize and more.

Ziplok

Learn and discover simple things

Meihta Dwiguna Saputra's Knowledge Base

~In learning you will teach and in teaching you will (re)learn~

The Java Blog

Thoughts, tips and tricks about the Java programming language

Sparkles

that were shone when I got tempered!

%d bloggers like this: