JBoss EAP6/AS7 Application Logging

JBoss EAP 6

Introduction

When it comes down to it, logging is one of the most important parts of an application. Logging, when done correctly, allows us to monitor code behavior and find bugs for example.

JBoss has its own implementation of the popular logging frameworks [log4j, apache commons, slf4j] that it lumps into a package called JBoss logging. The application platform utilizes a logging subsystem that manages your logs, instead of the traditional log4j.properties/log4j.xml files that the vast majority of Enterprise Java developers are acquainted with.  So, how can logging be configured to accomplish the logging behavior we desire? Is it possible to still use a log4j.properties? The short answer is read on and you will be able to correctly work with JBoss Logging, or if you want a traditional approach, then you will learn how you can bypass JBoss Logging and work with your own configuration as well.

This article will take a look at two logging strategies:

  • Logging with JBoss Logging
  • Logging without JBoss Logging [Traditional Logging Approach]

 

Logging with JBoss Logging

At the core, JBoss logging is log4j, so if you are familiar with log4j configuration, it should be a relatively easy transition to the new JBoss Logging. The main difference, other than syntax of course, is that the appenders from log4j are handlers in JBoss.

So, why convert to using the JBoss Logging, especially considering the next sections show how to avoid using JBoss Logging? Well, the short answer is, your logging becomes much easier to manage and interact with.  JBoss logging configuration goes into the standalone/domain xml files as all EAP 6 and AS 7 configuration does. The web console and the command line interface (CLI) tools both give you the ability to create and manage your logs. What’s more is, most all logging configuration happens on the fly, which means, you can crank your logs down to DEBUG to capture more information on an error state and turn it back to INFO without having to bounce your server.

Log Handlers

The log handlers are the appenders of JBoss logging.  You can add a console, periodic rotating file, and size rotating file handlers.  Each type (covered below) has some specific configuration required, some optional, and some that default to certain values if not set.

Console Handler

The console handler is used for logging out to the console as the name suggests.  The configuration for a console handler is pretty straight forward.

Property Required Default Description
autoflush No true Automatically flush after each write
encoding No undefined Character encoding to use
filter No undefined Filter to use
formatter No %d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n Defines a formatter
level No INFO The log level to set the handler to
target No System.out The target output

A command line example for adding a default console handler is as follows:

/subsystem=logging/console-handler=MyConsoleHandler:add

Which would  correspond to the following XML in the server xml configuration

<console-handler name="MyConsoleHandler"/>

Another example that changes some of the defaults is as follows

/subsystem=logging/console-handler=MyConsoleHandler2:add(autoflush=true,level=DEBUG,formatter="%-5p %d{yyMMdd HHmmss,SSS} %X{sessId} %c: %m%n")

Which would correspond to the following XML

<console-handler name="MyConsoleHandler2" autoflush="true">
    <level name="DEBUG"/>
    <formatter>
        <pattern-formatter pattern="%-5p %d{yyMMdd HHmmss,SSS} %X{sessId} %c: %m%n"/>
    </formatter>
</console-handler>

 

 

Traditional Logging Approach

So, let’s say you decide that JBoss Logging is not for you, and there are a number of reasons that you may decide this.  If you strive to keep your code container agnostic and would rather keep a traditional approach that will work on other platforms is one of the best reasons.  Or, if you are migrating your application from a previous version of JBoss, WebLogic, WebSphere, etc to EAP 6, for example, then you may not want to reconfigure all of your logging. Maybe you just don’t like the container controlling your Logging. Whatever the reason, you can pretty easily get your logging configuration working in a couple steps.

NOTE: The following will go over the basic steps FIRST, which will apply to just single deployments.  EAR deployments are slightly different in that it expands upon the single deployment steps and are covered in the last section below.

 

Disable JBoss Logging

In this step, the JBoss Logging jars are removed from the application. The JBoss jar’s have their own Log Manager which will not correctly pick up and will not use your logging configuration. In fact, you will likely get errors without this step.

Disabling JBoss Logging is done on an application basis in the jboss-deployment-structure.xml file. This does allow for you to have some apps using JBoss Logging and some using their own Log Manager, however, I strongly suggest using one strategy or another for all applications.

As before, we will stick with Log4j and Apache Commons Logging, however, you can use SLF4j or similar with the same basic approach.

<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.2">
    <deployment>
        <exclusions>
            <module name="org.apache.log4j"/>
            <module name="org.apache.commons.logging"/>
        </exclusions>
    </deployment>
</jboss-deployment-structure>

If you are using an EAR, then please skip to the section below discussing EAR deployments. If you are using a WAR, then this file is placed in your WEB-INF directory.

Package the Logging JARs and Configuration

You will now package your logging JARs inside of your application.  This would be inside your lib directory of your EAR or your  WEB-INF/lib directory of a WAR as normal.

You will also place your log4j.properties/log4j.xml on your classpath as normal.

Add a JAVA_OPT to Startup

Now, when starting the application server, you will need to add a JAVA_OPT.  This flag will make sure that the JBoss Log Manager does not pick up your logging configuration and your own logging JARs will work as normal.

./standalone.sh -Dorg.jboss.as.logging.per-deployment=false

And now your application will now log using the packaged JARs, effectively bypassing JBoss Logging.

EAR Deployments

Now, the above example is all fine and good if you are deploying a WAR, however, Enterprise applications typically have multiple deployments packaged in an EAR.  If you try the above method, then the JBoss Log Manager will ignore your configuration and use the containers logging subsystem.

For EAR packages, the jboss-deployment-structure.xml, first of all be in the EAR’s META-INF directory.  Additionally, you must add exclusions for the deployment AND each sub-deployment. The logging jars should be in the EAR/lib directory.  You should create a module that you can use to bring in the log4j.properties file so all sub-deployments can reference it.  Finally, you must start with the JAVA_OPT as noted above.

Example jboss-deployment-structure.xml file

<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.2">
        <deployment name="logging-war-1.0.war">
                <dependencies>
                        <module name="com.jyore.logging" export="true"/>
                </dependencies>
                <exclusions>
                        <module name="org.apache.log4j"/>
                        <module name="org.slf4j"/>
                </exclusions>
        </deployment>
        <sub-deployment name="logging-war-1.0.war">
                <exclusions>
                        <module name="org.apache.log4j"/>
                        <module name="org.slf4j"/>
                </exclusions>
        </sub-deployment>
</jboss-deployment-structure>

Example module.xml

<?xml version="1.0" encoding="UTF-8"?>  
<module xmlns="urn:jboss:module:1.1" name="com.jyore.logging">  
    <resources>  
        <resource-root path="."/>  
    </resources>  
    <dependencies>  
        <module name="org.apache.log4j"/>  
    </dependencies>  
</module>

Example module layout

I included a project and the module for your own testing. Enjoy!

Downloads: logging-example.zip | modules.zip

Share on Facebook+1Share on Twitter Share
Posted in Programming Tagged with: , , , , , , ,
13 comments on “JBoss EAP6/AS7 Application Logging
  1. Pravin Jose says:

    I was facing issues with logging after we migrated our application from JBoss 4.2.2 to JBoss AS 7.
    Thank you very much for this information. After reading this article I added jboss-deployment-structure.xml file to disable jboss logging and continue using the traditional logging approch utilizing the already existing log4j.properties file. This resolved my logging related issues with JBoss AS 7.

  2. How would a .war app using java.util.logging.Logger configure the boss-deployment-structure file. Its an errai project from https://github.com/errai/errai-tutorial/archive/master.zip and I no longer see server-side log output after switching to EAP 6.1

  3. Ravi Balla says:

    Thank you, Thank you. I had been struggling with logging for a whole day. Lot of googling and trying to find the solution. This blog was up to the point and accurate. Solved my issue. Again, many thanks.

  4. Reinhard says:

    Thanks a lot for the interesting read.
    What a pity that the file handler sections are still to be filled in. I’m hoping to find out about autoflush, which the JBoss 7 administration console defaults to false when you add a new handler. At what point are messages written to file when autoflush is false?

  5. c says:

    God bless you!

  6. Shailendra Shahane says:

    Thanks a lot ! I was having problem in EAR deployment while using my own logging mechanism (existing) . We were basically porting from Jboss 4 to AS 7. The above steps worked fine for me.
    One point – I kept the Logging jars (Apache and SLF4j) in the same module(Custom module for logging) and rferred to them via dependency tag inside deployment tag in the jboss-deployment-structure.xml
    So the logging jars need not be in EAR/lib. They work in Module too.

    • Joey Yore says:

      Yes, you can use a module instead of packaging in the ear/war, and that is definitely recommended if you are deploying multiple apps. Thanks for adding the note

  7. Eric Rizzo says:

    My app is using slf4j as its logging API and logback as the provider. The logback configuration includes a console (std-out) appender for running JBoss in the IDE (so we see logging output in the IDE console when running locally).
    I added the log4j and commons-logging exclusions to the JBoss configuration and am passing the “per-deployment=false” system property, and yet JBoss is still capturing all std-out and wrapping it, which effectively removes our ability to control levels and format via logback.xml. Any ideas what else can be done to get JBoss to totally stop capturing and wrapping output?

    • Joey Yore says:

      Try removing the console appender in your standalone.XML file. The subsystems will still log out through that which is probably what you are seeing

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">