First8 staat voor vakmanschap. Al onze collega’s zijn een groot aanhanger van Open Source en in het bijzonder het Java-platform. Wij zijn gespecialiseerd in het pragmatisch ontwikkelen van bedrijfskritische Java toepassingen waarbij integratie van systemen, hoge eisen aan beveiliging en veel transacties een belangrijke rol spelen. Op deze pagina vind je onze blogs.

Configuring SLF4J in Wildfly

Logging in the Java world unfortunately is complicated. Due to Parkinson’s Law of Triviality we ended up with an endless list of libraries that provide logging capabilities, up to the point where Sun (when it still existed) decided to step in with JUL (java.util.logging) in JDK 1.4. Too little, too late and it only added to the complexity.

These days the general advice is, especially for library builders, to use SLF4J which actually doesn’t provide logging capabilities. It is merely a facade (hence the name) for any of the existing libraries. When packaging your application, you can add a binding jar which provides an adapter from SLF4J to whatever framework you want to use. The nice thing is that you can decide this at the very latest moment, just before you actually run the application. This allows your application to join an existing logging framework.

If you are going to deploy your application in an application container like Wildfly, it makes sense to simply use what is made available. Although there isn’t much documentation, it looks like Wildfly itself uses its own facade, similar to SLF4J. If you use a supported logging framework like LOG4J, it will automatically be redirected into the Wildfly logging. No need to add dependencies for that since it is already packaged with Wildfly.

Of course, your IDE still needs to know how SLF4J’s API works even though it doesn’t have to package it with the WAR. So we’d need to declare a provided scope in your Maven pom for SLF4J. Wildfly 9.0.1 happens to ship with 1.7.7. ( a ls -R|grep slf4j-api in the Wildfly directory will tell you quite nicely if you can’t find it in the documentation.)

There is of course another way. For Wildfly there are so-called BOM’s (Bill of Material) defined; handy dependencies for getting the right versions. Normally, including the jboss-javaee-7.0-with-all in dependencyManagement should be enough. However, this does not include dependencies used in its core system (see this question). So we add an additional dependency on wildfly-parent. (Note that this is dependencyManagement so we don’t actually pull in all the dependencies, just the versions).

We are not done yet… If you want to use SLF4J, Wildfly needs to provide access to those jar files. So we need a trick to make Wildfly aware that we are going to be using SLF4J. We can do that in two ways, via a JBoss deployment descriptor or via the MANIFEST.MF file.

1) jboss-deployment-structure.xml

One way is to create a file jboss-deployment-structure.xml in the META-INF folder:

<?xml version="1.0" encoding="UTF-8"?>
<jboss-deployment-structure>
  <deployment>
    <dependencies>
      <!-- add your project dependencies here -->
      <module name="org.slf4j" />
    </dependencies>
  </deployment>
</jboss-deployment-structure>

2) MANIFEST.MF

We could also specify this dependency in a MANIFEST.MF file. In this case, we could create it ourselves, or let Maven handle it:

This will create a MANIFEST.MF file which will look something like this:

With this, your application should be able to log using SLF4J. Don’t forget to tweak and tune your loglevels in the administrative console of Wildfly (on localhost it would be found here: http://localhost:9990/console/App.html#logging)

Read more: