Why the slf4j-jdk14 artifact was optional
Posted by danielmeyer on August 15, 2008
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!