I learned about one of those wonderful issues that crop up in software development that are just about impossible to plan for. One of my senior developers who’s rolling out a small Hibernate project mentioned they had run into an issue with Oracle 10g. This was the first project we’ve used 10g on, but all of a sudden he started getting strange errors when he tried to generate the schema on the fly. After some frustration it turned out that DROP doesn’t really mean DROP in 10g. Oracle has added the idea of a recycle bin so that you can recover the table. A quick removal of the default setting and the problem was solved.

I’ve had to configure Log4J several times over the years and I’ve never particularly enjoyed the experience. Log4J is in general just not well documented, surprisingly so since it is used extensively in the Java world.

So I found myself going through some examples in the first part of Spring in Action and needing to configure Log4J. So off to the Log4J site only to run into familiar problems:

• Most of the documentation forgets to mention the easiest way to configure Log4J so that you don’t have to explicitly load a file is to add log4j.xml to the CLASSPATH.
• Almost all the documentation and tutorials show log4j.properties instead of log4j.xml
• The documentation and tutorials don’t explain most of the options for the XML tags.
• There just isn’t a good solid recent tutorial. (Or at least I haven’t run across it)

So I’m documenting my Log4J setup, mainly so I don’t have to research it again sometime down the road. The two best tutorials I could find were ‘Don’t Use System.out.println()! and Log4J Tutorial by Ashley J.S Mills. The first details most of the options for layout parameters and focuses on the log4j.properties format. The XML configuration is better covered Ashley J.S. Mills article.

Following below is my sample log4j.xml file:

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE log4j:configuration SYSTEM "log4j.dtd">

<log4j:configuration xmlns:log4j="http://jakarta.apache.org/log4j/">
  <appender name="ConsoleAppender" class="org.apache.log4j.ConsoleAppender">
    <layout class="org.apache.log4j.SimpleLayout"/>
  </appender>
  <category name="com.springinaction.chapter01">
    <priority value="debug"/>
  </category><root><priority value="info"/>
    <appender-ref ref="ConsoleAppender"/>
  </root>
</log4j:configuration>

The appender section simply defines a Console Appender and a simple layout. The category section defines a package and a priority level. It’s important that you put this before the root section apparently in the file or you get errors. If you want to log all the debug statements just from your stuff you leave this set to debug. This overrides the root section. The root section is ‘required’ or again you get errors about Log4J configuration. In this case its set to ‘info’ for the priority so I don’t get a bunch of debugging messages I don’t care about in the Spring framework.

Finally you can then use Log4J in any class by adding the following instance variable:

Logger log = Logger.getLogger(Sample.class);

Then when you want to dump something to the logger a simple call:

log.debug("Entering printThis() Method");

This simple example doesn’t show File Appenders or nicely formatted statements with date and time stamps, but it does show the bare minimums to get up and running, so hopefully I’ll never have to research it again.

My actual opinion of loggers is that they often are signs of bigger problems such as insufficient unit tests. Loggers can be overused as a basic debugging strategy. I prefer to go back and write more unit tests rather than rely on logging to debug a problem. They also tend to clutter up code, though that will theoretically become less of a problem with AOP strategies. Still they’re generally handy especially for debugging production issues.

I’ve run across a few developer podcasts worth listening to on my morning walks. Drunk and Retired was a nice surprise. It has some low brow humor, cursing, and personal stories on non-software topics, but it manages to be a good back and forth between Charles and Cote. They’ve both been developers for 10 years or so. Charles is currently in Europe living the software developer’s version of the rock and roll lifestyle as an independent software developer, and Cote is recently married and working for a large corporate shop.

The topics cover wide ranging current topics from Rails to Domain Specific Languages. Cote and Charles tend to be disparaging of most of these bleeding edge technologies, but their criticisms stem generally from hard experience or at least based on wild speculation. Give them a listen if you’re geeky enough to enjoy development podcasts.

I came across yet more anecdotal evidence that actual JSF adoptions are coming along pretty slowly, from some commentary by Greg Luck. During a session on web frameworks with Craig McClanahan and Matt Raible at O’Reilly’s Open Source Conference apparently a question was asked about who in the audience was using JSF:

It is a little unclear what will happen with JSF. It has been coming for a long time, but only one person in the audience was using it.

This points again towards the idea that despite all the talk about JSF, there are still few people using it. And I’ll probably get flamed about this since the technology has some hardcore true believers. For me it’s on the wait and see list of new technologies. I’m still not convinced its worth the effort to adopt and that something better is likely to come along.

Read through a few posts over on the Subversion site after someone pointed to it. So apparently VSS will finally follow the Dodo bird off a cliff. It’s about time!

VSS had always been an amazingly bad version control system. I worked for an ecommerce dotcom back in 2000 where VSS was the default source control system. After one of our uber developers wrote his own proxy service for a client with about 500 classes he tried to check it in. Since VSS assumes it’s on a local network share and we were actually on a VPN with limited bandwidth to the corporate office in SF it took 8 hours and failed on the initial attempt. Just getting a directory listing in VSS took minutes sometimes.

Anyway after he had to fly out to the SF office to successfully check it in, the company considered moving to CVS. The final nail in the coffin were the explanations from our handful of ex-Microsoft developers. As one of them put it, “Oh, we never used Source Safe at Microsoft, it doesn’t scale.”