Configuring the application server logging

Every application needs to trace logging statements. At the moment, there are several implementations of logging libraries for Java applications, the most popular ones are:

Log4j: It is a flexible open source logging library from Apache. Log4j is widely used in the open source community, and it was the default logging implementation on earlier releases of JBoss AS.

J2SE logging libraries (JUL): It provides the logging classes and interfaces as part of the J2SE platform’s standard libraries.

Log4j and JUL are indeed very similar APIs. They differ conceptually only in small details, and in the end do more or less the same thing, except Log4j has more features that you may or may not need.

JBoss logging framework is substantially based on JUL, which is built around three main concepts: loggers ,handlers , and formatters . These concepts allow developers to log messages according to their type and priority, to control where messages end up and how they look when they get there.

The following image shows the logging cycle using the JUL framework. Applications make logging calls on Logger objects. These Logger objects allocate LogRecord objects, which are passed to Handler objects for publication. Both the Logger and the Handler may use the Formatter to arrange the layout of logs and Filter to decide if they are interested in a particular LogRecord.

Choosing your logging implementation

JBoss AS, through its releases, has used different frameworks to handle application server logs. In JBoss AS 5 and earlier, log4j was the default logging API used by the application server, and it was defined in the server//conf/jboss-log4j.xml file.

Since JBoss AS 6, the logging provider switched to JBoss’s own implementation, which is based on the JDK 1.4 logging system. However, it provides several fixes or works around many serious problems in the default JDK implementation.

For example, the default implementation of java.util.logging provided in the JDK is too limited to be useful. A limitation of JDK logging is the inability to have per-web application logging, as the configuration is per-VM.

As a result, JBoss AS replaces the default JUL LogManager implementation with its own implementation, which addresses these shortcomings. The following image illustrates the modules that make up the JBoss AS 7 logging subsystem:

At the top of the hierarchy there’s the org.jboss.logmanager module, which is the top-level library that manages logs for the jboss logging subsystem. Beneath the jboss logmanager, you can find the concrete implementations, such as the org.jboss.logging or the jboss-logmanager-log4j module. By default, the application server uses the former module (org.jboss.logging), which is implemented in its turn by org.jboss.as.logging to manage your logs inside the application server. However, if you want to switch to log4j implementation, the jboss-logmanager-log4j module is what you need (in the last section of this chapter, we will include an example of how to use log4j in your application).

Configuring the logging subsystem

The logging subsystem contains a set of log handlers out of the box. A handler object takes log messages from a logger and exports them. It might, for example, write them to a console or write them to a file, or send them to a network logging service, or forward them to an OS log, or whatever. By default, the following handlers are defined:

The console-handler

The console-handler defines a handler, which simply writes log messages to the console.

The attributes of the console-handler are common to all other handlers. We will shortly describe their meaning here:

The optional autoflush attribute determines if buffered logs are flushed automatically. The default value for this option is true.

Frequently asked Jboss Interview Questions

The following element, level, defines the log level associated with the handler, ranging from FINEST (lower level) to FATAL (highest value).

Then, the formatter element provides support for formatting LogRecords. The log formatting inherits the same pattern strings for layout pattern of log4j, which was in turn inspired by dear old C’s printf function.

For an exhaustive list of logging formats, you can check the log4j documentation at https://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/PatternLayout.html.

Here, we will just mention that %d{HH:mm:ss,SSS} outputs the date of the logging event using the conversion included in brackets.

• The string %-5p will output the priority of the logging event
• The string [%c] is used to output the category of the logging event
• The string (%t) outputs the Thread that generated the logging event
• The string %s outputs the log message
• Finally, the %n string outputs the platform-dependent line separator character or characters

The periodic-rotating-file-handler

The periodic-rotating-file-handler defines a handler that writes to a file, rotating the log after a time period derived from the given suffix string, which should be in a format understood by java.text.SimpleDateFormat.

Here’s the definition of it:

This handler introduces the file element containing the path, which is the actual filename and its relative-to position. In our case, the relative position corresponds to the jboss.server.log.dir application server parameter.

Note

With the default suffix configuration, logs are rolled at 12 PM. By changing the SimpleDateFormat, you can also change the period when logs are rotated, for example, the suffix yyyy-MM-dd-HH will rotate the logs every hour.

The size-rotating-file-handler

The size-rotating-file-handler defines a handler that writes to a file, rotating the log after the size of the file grows beyond a certain point. It also keeps a fixed number of backups.

There’s no size handler defined in the standard configuration. However, we can find out its basic configuration from the JBOSS_HOME/docs/schema/jboss-as-logging.xsd file:

The asynchronous handler

The asynchronous handler is a composite handler, which attaches to other handlers to produce asynchronous logging events. Behind the scenes, this handler uses a bounded queue to store events. Every time a log is emitted, the asynchronous handler appends the log into the queue and returns immediately. Here’s an example of asynchronous logging for the FILE appender:

In this handler, we are also specifying the size of the queue where events are sent and the action to take when the async queue overflows. You can opt between blocked where the calling Thread is blocked, and discard where the message will be discarded.