Why the slf4j-jdk14 artifact was optional

Man, are these posts deep-soup technical these days, or what?  I’m afraid all my non-techie friends must have given up in despair some time back…  Ah well, trudging on:

Last time I made a comment about how I thought the slf4j-jdk14 artifact should be marked as a non-optional dependency in Bitronix Transaction Manager’s pom file.  Well, I was wrong.  Here’s why:

slf4j is a façade — something like an interface that can be implemented different ways.  The BTM project does depend on slf4j-api, but it’s apparently up to the dependent project (me) where I want those debug messages to go to.  I choose where I want ’em to go by installing one of the slf4j providers, such as slf4j-jdk14 (routes to the JDK logger), slf4j-log4j12 (routes to log4j), etc.  Ludovic has explained this to me and pointed me to the BTM page that explains it.  (I think I had glanced at that page before, but at that time I didn’t understand what I was seeing.)  I understand now why BTM doesn’t make the slf4j-XXXX dependency non-optional: that would be choosing an implementation of the slf4j-api, and that decision should be left to the user of BTM (me!)

Fixing my project

Not realizing that there were different implementations of slf4j-api, I had added slf4j-jdk14 to my pom file, which meant that most of BTM’s debug messages were routed to the JDK logger, which I’m not using, so they were being lost.  I just need to change that dependency to this:

        <dependency>
            <groupId>org.slf4j</groupId>
            <artifactId>slf4j-log4j12</artifactId>
            <version>1.4.3</version>
            <scope>runtime</scope>
        </dependency>

Now when I add this line to my log4j.properties, I get more DEBUG-level output from the BTM classes.

Thanks for the help, Ludovic!