Enable logback in JBoss

Leon - March 16, 2015 - 10 comments

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.

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

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">
        <resource-root path="logback-classic-1.1.1.jar"/>  
        <resource-root path="logback-core-1.1.1.jar"/>  

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

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:

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


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 -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">
        <filter class="ch.qos.logback.classic.filter.ThresholdFilter">
        <rollingPolicy class="ch.qos.logback.core.rolling.FixedWindowRollingPolicy">
        <triggeringPolicy class="ch.qos.logback.core.rolling.SizeBasedTriggeringPolicy">
            <pattern>%r %d{ISO8601} %m%n</pattern>

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:

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


This is it.

Enjoy 😉




  1. tasos

    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:

  2. tasos

    Commented out in #1:

  3. tasos

    handler name=”CONSOLE”
    handler name=”FILE”

  4. Valentin

    Excellent ! Work like a charm with Wildfly 10 !

    • Kir Merzlikin

      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 🙁

  5. john

    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?


  6. dsylenko

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

    causes some kind of locking while running multiple methods with annotations:
    so countdownlatch waits forever for async methods execution.

  7. Martin


    Thanks a lot for the post! It has been imposible to find a solution witch actually works in JBoss 6.4!
    Logs are printed perfectly to files.
    However, I can’t make it work for logback’s ConsoleAppender (target=System.out) in local machine. Any idea why?


  8. Brad

    Wildfly / JBoss EAP use JBoss Logging not Log4j, Log4j and the other logging APIs proxy to JBoss Logging. Logback is fronted by SLF4j , so what are you gaining by changing the logging implementation? Other than creating an unsupported/untested configuration?

Post a Comment

Your email address will not be published.