Enable logback in JBoss

About 10 years ago log4j was the logging framework for java. Years passed and many logging frameworks emerged. For many people, including myself, logback is the new log4j (and that is not only because of Ceki).

Unfortunately it is not possible to run logback as slf4j implementation OOTB in JBoss like in Tomcat. The following 5 steps explain you how to get it running.

Please note: this guide is for JBoss Wildfly. Other versions may differ.

 

Step1: Set slf4j as logging provider in standalone.xml

Add following block right after extensions in your standalone.xml.

<system-properties>
    <property name="org.jboss.logging.provider" value="slf4j"/>
</system-properties>

Step2: Install or create logback module

To enable logback, you’ll need a module. This is pretty straightforward. First create a new directory in your JBoss:

mkdir $JBOSS_HOME/modules/system/layers/base/ch/qos/logback/main

put your logback implementation into the folder, in my case: logback-classic-1.1.1.jar and logback-core-1.1.1.jar. Now create a file named module.xml and put following content into it:

<?xml version="1.0" encoding="UTF-8"?>

<module xmlns="urn:jboss:module:1.1" name="ch.qos.logback">
    <resources>
        <resource-root path="logback-classic-1.1.1.jar"/>  
        <resource-root path="logback-core-1.1.1.jar"/>  
    </resources>

    <dependencies> 
        <module name="org.slf4j" />  
        <module name="javax.api" />  
        <module name="javax.mail.api" />  
    </dependencies>
</module>

Keep attention, that the version numbers in the filename and module definitions are the same.

 

Step3: Tell JBoss to use slf4j and logback for logging

Open $JBOSS_HOME/modules/system/layers/base/org/jboss/logging/main/module.xml

Remove dependency to org.jboss.logmanager and add dependencies to logback and slf4j instead. The resulting dependencies section should look like this:

<dependencies>
  <module name="org.slf4j"/>
  <module name="ch.qos.logback"/>
</dependencies>

 

Step4: Add logback.xml

You need to add logback.xml. A good place is $JBOSS_HOME/standalone/configuration. Of course it would be better to have it in the project, but JBoss does weird things to the contents of the project, and you might want to edit the configuration at runtime. For development environment you may want to link it to your source code location.

Tell logback where to look for the log files via VM Property in standalone.sh

export JBOSS_PATH=path-to-my-jboss-installation
export JAVA_OPTS="$JAVA_OPTS -DJBOSS_LOG_DIR=$JBOSS_PATH/standalone/log"
export JAVA_OPTS="$JAVA_OPTS -Dlogback.configurationFile=$JBOSS_PATH/standalone/configuration/logback.xml"

Sidestep: it is convenient to define the logfile location based on JBOSS_HOME in your logback.xml:

    <appender name="RequestLogAppender" class="ch.qos.logback.core.rolling.RollingFileAppender">
        <file>${JBOSS_HOME}/standalone/log/mylogfile.log</file>
        <filter class="ch.qos.logback.classic.filter.ThresholdFilter">
            <level>INFO</level>
        </filter>
        <rollingPolicy class="ch.qos.logback.core.rolling.FixedWindowRollingPolicy">
            <fileNamePattern>${JBOSS_HOME}/standalone/log/mylogfile.%i.log</fileNamePattern>
            <minIndex>1</minIndex>
            <maxIndex>5</maxIndex>
        </rollingPolicy>
        <triggeringPolicy class="ch.qos.logback.core.rolling.SizeBasedTriggeringPolicy">
            <maxFileSize>100MB</maxFileSize>
        </triggeringPolicy>
        <encoder>
            <pattern>%r %d{ISO8601} %m%n</pattern>
        </encoder>
    </appender>

Step5: Set logback as slf4j implementation.

JBoss comes with its own slf4j implementation which is … well, you don’t want it. To enable logback as slf4j implementation edit $JBOSS_HOME/modules/system/layers/base/org/slf4j/main/module.xml and set:

<dependencies>
    <module name="ch.qos.logback"/>
</dependencies>

 

This is it.

Enjoy 😉

 

 

7 thoughts on “Enable logback in JBoss

  1. Hi!
    Excellent post!
    It all works quite well. However, Wilfly still logs in the server.log file and in CONSOLE. Not sure if logging.properties is still being used, but the result is a little weird combination of both log4j and logback…
    What I’m seeing is something like this, where the first part is related to log4j and the second part to logback (see 2 timestamps):
    19:11:28,596 INFO [stdout] (MSC service thread 1-6) 19:11:28.596 [MSC service thread 1-6] DEBUG org.jboss.as.config: VM Arguments: -D[Standalone] -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true -DJBOSS_LOG_DIR=/opt/wildfly/wildfly-8.2.0.Final/standalone/log -Dlogback.configurationFile=/opt/wildfly/wildfly-8.2.0.Final/standalone/configuration/logback.xml -agentlib:jdwp=transport=dt_socket,address=8787,server=y,suspend=n -Dorg.jboss.boot.log.file=/opt/wildfly/wildfly-8.2.0.Final/standalone/log/server.log -Dlogging.configuration=file:/opt/wildfly/wildfly-8.2.0.Final/standalone/configuration/logging.properties

    The standalone.sh adds the last 2 JVM properties, which seem to cause the complication.

    Anyway, I have managed to disable this logging side-effect by doing 2 things:
    1. Updated standalone.xml:

    <!–

    –>

    2. Updated logging.properties with:
    handler.CONSOLE.enabled=false
    handler.FILE.enabled=false

    • Can you please share your configuration for Wildfly 10?
      After doing everything, that’s described in the article, I still see either collapsed log messages from both logging systems or messages from jboss logging only 🙁

  2. When I did this on 7.1.1, after starting jboss, i saw my application did not successfully deploy cause when jboss started thee was a classnotfoundexception for class file ch.qos.logback.ext.spring.web.LogbackConfigListener

    this file was not in either of the qos.logback jar files you mentioned above? has anyone else had this happen?

    John

  3. Hi,
    Just FYI, on wildlfy 8.2, step
    >>Remove dependency to org.jboss.logmanager

    causes some kind of locking while running multiple methods with annotations:
    @Asynchronous
    @TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)
    so countdownlatch waits forever for async methods execution.

Leave a Reply

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

*