Log file goodness

I’m learning to see the helpfulness of good logging.  There’s already a good logging discipline here around me.  My program was terminating abnormally and I couldn’t figure out where the problem was coming from.  I fired up the debugger* and was able to figure out what the problem was.  Then I looked back in the log files to see if I could have divined from the log output where the issue was.  Yes, I could have.  Here’s the end of the log file:

Notice all the functions being entered, but not left?  (the squares with arrow pointing to right)  We can see that about the last thing that’s in process is loading from an xml file.  I checked my machine and …I was missing that xml file.  I could have saved myself a lot of wasted time fiddling with my source code, reverting to previous versions, rebooting machines, and the like, if I had been able to recognize the signs of something wrong when I looked at this the first time.

*(without copying source code — how that worked is worthy of a separate post)

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!