Configuring loggers

 

A Logger object is used to log messages for a specific system or application components. Loggers are normally named, using a hierarchical dot-separated namespace. Logger names can be arbitrary strings, but they should normally be based on the package name or class name of the logged component. For example, the logger instructs the logging system to emit logging statements for the package com.sample, if they have the log level “WARN” or higher:

At the top of the hierarchy, there’s the root-logger. It is exceptional in two ways: It always exists It cannot be retrieved by name In the default server configuration, the root-logger defines two handlers, which are connected to the CONSOLE and to the FILE handler:

Configuring log4j in your application

So far, we have seen how to configure the application server logs operating on the main configuration file (standalone.xml). Chances are, however, that users will want to provide a log configuration on an application basis, using the widely adopted log4j framework. This section shows the simple steps needed to adopt log4j in your application.

Let’s create a basic web application named LogExample. For this purpose, you can start a New Dynamic Web project from the Eclipse IDE. In order to configure log4j, we will need to provide a log4j configuration file, which, by default, is named log4j.properties or log4j.xml, and place it at the root of the Java sources (named src in Eclipse).

The following sample, log4j.properties, defines two appenders: the first one (stdout) prints messages on the console, while the second one(R) is connected with a RollingFileAppender:

log4j.rootLogger=warn, stdout, R

# stdout is set to be a ConsoleAppender.

log4j.appender.stdout=org.apache.log4j.ConsoleAppender

# stdout uses PatternLayout. log4j.appender.stdout.layout=org.apache.log4j.PatternLayout

# Pattern to output the caller’s file name and line number. log4j.appender.stdout.layout.ConversionPattern=%5p [%t] (%F:%L) – %m%n

# R is set to be a RollingFileAppender. log4j.appender.R=org.apache.log4j.RollingFileAppender log4j.appender.R.File=example.log

# Max file size is set to 100KB log4j.appender.R.MaxFileSize=100KB

# Keep one backup file log4j.appender.R.MaxBackupIndex=1

# R uses PatternLayout.

log4j.appender.R.layout=org.apache.log4j.PatternLayout

log4j.appender.R.layout.ConversionPattern=%p %t %c – %m%n

log4j.logger.com.packtpub=DEBUG, stdout, R

As we said, this file will be placed at the root of your web project, so that when the project is built, it will be moved in the WEB-INF/classes folder of your web application that is visible to the application’s classpath.

Frequently asked Jboss Interview Questions

Additionally, place the log4j libraries in the WEB-INF/lib folder of your application. Here’s how the Web application should look:

Now, you can add logging statements to your classes, and they will be intercepted by the console appender and by the file appender. For example, the following Servlet prints out the value of the System variable named myproperty, which has been added earlier in the server configuration file:

@WebServlet(“/LoggerServlet”)
public class LoggerServlet extends
HttpServlet {
private static org.apache.log4j.
Logger logger = org.apache.log4j.
Logger.getLogger(LoggerServlet.class);
protected void doGet(HttpServletRequest request, HttpServletResponse response) 
throws ServletException, IOException {
logger.info(“System variable myproperty=”+System.getProperty(“myproperty”));
PrintWriter out = response.getWriter();
out.println(“The Servlet just logged.”);
}
}

Why have we added log4j library to the application?

If you try to deploy your application without the log4j library, you will find that the deployer raises a ClassNotFoundException on the classes using the log4j package. This can be a bit surprising, since log4j libraries are indeed included in the application server modules.

The explanation to it is that JBoss AS 7 is not based any more on a hierarchical class loader, but it is entirely based on module classloading. This means that in practice, each deployment unit is itself a module, which is isolated from other modules, such as .jars that are included in the application server.

The first good news is that you will not face any more conflicts between the application classes and the server classes, also known with the infamous epithet classpath hell.

The second good news is that you can easily override the default (isolating) behavior by simply adding a dependency on other modules installed. For example, in this case, you would need to add a dependency on org.apache.log4j module so that log4j libraries are automatically linked by your application. Deploying Applications on JBoss AS 7,