For something that seems like the simplest task, logging in Java is one of the more hotly debated and hard to figure out issues. It's not that people don't want to log messages about what's going on, and it's not that users don't want nice messages telling them what is happening. The problem comes down to deciding exactly how to log messages. Pick your favorite open source project and add ‘logging' to a Google search and you're sure to come up with at least 10 threads with developers arguing 8 different sides of the argument.

Currently there are a number of options to choose from:

• The built-in java.util.logging. This would seem like the obvious choice since everyone already has it, however configuration and options for what happens to the messages have always been lacking. Just getting file to roll over every night requires custom code. Getting messages to go to an NT event log or something else more exotic is even worse.

• Log4j: This was one of the first and better frameworks for logging in Java that had a well thought out configuration model and a number of prebuilt appenders so you can log messages to files, event logs, and so on. This project hasn't had much work done on it recently, but it remains one of the more popular despite this fact.

• Logback: A newer framework meant to replace log4j and fix some of its weaknesses in addition to being faster.

• Custom / Home grown logging. This is the worst as you're totally locked in and few of these tools have robust configuration capabilities.

Four choices aren't so bad but then the meta-loggers come in. Basically developers realized that if you picked framework ‘A' and I picked framework ‘B' and we want our components to work together, we need some way to bridge that gap. The choices in this arena are:

• Commons-logging: A relatively old Apache project that can write to a number of underlying logging frameworks. It is most famous for causing countless classpath headaches but once configured properly, works quite well. Its problems have been heavily documented. Even the author of commons logging admits its short comings.

• SLF4j: A relatively new framework designed to work like commons logging to an extent, but uses static binding to mitigate classpath issues. In addition they've added a whole suite of ‘legacy' compatibility tools to allow you to take over all the previously mentioned frameworks.

If you're developing a product in today's environment, you're likely to be using at least one or two open source libraries, and the chances of those libraries using the same framework are rare. Luckily it seems like many open source project s are starting to converge or are at least getting easier to deal with. For instance:

• Lucene might be moving to slf4j.

• SOLR already moved to SLF4j.

• Apache HTTP client uses commons logging which is easy to hook into SLF4j.

• Jetty is using SLF4j.

The nice thing about SLF4j is that it gives users the ability to choose. Using SLF4j's legacy bridging capabilities, you can coalesce messages from any framework into a single API. From there you can have it send all the messages back out to whatever destination you want. At Attivio, we ended up choosing SLF4j for this reason and because it was what many of the projects we work with use or were easy to make use. We then ship with log4j jar and configuration files since it's currently the most popular way to get messages back out to the end user. In the end, it's all about end users being able to do what they want with log messages and how they want. If a customer of ours wants everything to go with java.uti.logging because that is what they have standardized on as a company, then they can switch without having to even call us. If however, they want to stick with log4j but want messages from their custom code and a random 3rd party library they use to go to a unix syslog, they can do that too, again with no assistance from us necessary. Now if we could just get everyone else to agree....

Author Bio

Since graduating from MIT with a degree in Computer Science, Will Johnson has worked for Altavista and FAST for over 7 years. At Altavista Will developed AV's real time indexing solution used by news aggregators who demanded instantaneous access to news as it arrived. In addition he was one of two engineers responsible for developing the Altavista QIndexer product that was used by the large majority of AV's customers. At FAST, Will developed high speed database connectors as well as developing search UI's and tool sets used across the organization. In addition Will also worked on many of the largest and most complex sales engagements and deployments for customers around the world, specializing in distributed systems for many of the largest internet publishers, directories as well as internal knowledge management systems. Will is a founder, one of the Chief Architects at Attivio and a really nice guy.

TrackBack URI for this entry

Comments (0)