LogBack on Zero

novembro 6th, 2008 | by Aldrin Leal |

(Another tech post. Yes, I’ve been all about logging frameworks lately. If you think I should start another blog, this time on tech in plain english, feedback on the comments section.)

Ok, now that zero.firephp is here, its time to dissect ProjectZero itself. It was not pleasant to deal with the ivy files, so lets get started before I remember how painful it was to deal with a cheap M2 rip-off.

Java Logging 101: The History

(Skip to the next section if you already know about this)

In the end, there was System.out. And this was good.

People then started to wonder that if would be helpful to separate logging statement from application output. Thus, Unix programmers quickly rushed to System.err, already in the knowledge it was a safe harbor. So now people could enable and disable logging. And that was good as well.

However, people started to notice that when logging was on, performance was down while copious amounts of logging data were written as well. So, Java people borrowed the concept of Logging Levels and started put simple statements to test before logging.

Then, people wanted to have the ability to save output into a file. Perhaps for daemons, or perhaps just to keep a copy handy to look and compare with other. Thus, the logging flags to file output were born.

Then, Ceki Gülcü (aka “The God of Logging ”) came and thought it was a good idea to mix the hierarchy java uses in the package system, mix levels, analyze and came up with Log4J. That was excellent, and several other frameworks were made after his one.

Soon, a company with the Stock Symbol “JAVA” on NASDAQ thought it would be good to bless. What a mess (it rhymed!)… The java.util.logging package was born, and this was not good, culminating in flame wars (vi-versus-emacs-style) in Apachia, a small micronation on the internets.

The overlords at commonia, a small county within Apachia , in an attempt to restore peace and ensure Apachia’s economical growth, devised commons-logging, an ill-fated that while good in nature (trying to automagically bridge logging requests between log4j and java.util.logging), in truth created another layer of abstraction which is still useful today, but creating a third logging API which also brought some nasty classloading issues.

Ceki Gülcü left apache, and log4j 1.3 was soon left deprecated. 2.0 is said to be still in the works. Meanwhile, Ceki came back and revised the concepts between commons-logging and log4j, creating slf4j and logback, respectively, trying to narrow the gap and bring his vision back to the world. It also includes libraries to bridge java.util.logging and plug-in replacements for log4j as well as commons-logging.

In the end, we have 5 apis, all of them completely different.

Oh god… I miss System.out.

Zero

Zero uses java.util.logging. Being a good citizen of the Java World, seems fine. But if you want to use logback, its possible. In particular, download this file, unpack and keep going, as I will outline the steps required to enable logback and, as a bonus, see zero logging under Lilith, a handy logging viewer for logback.

Step #1: Declare the Dependencies

Take the enclosed ivy.xml. Merge the section outlined below into your ivy.xml:

You’re inserting the APIs required slf4j  (transitively, from jul-to-slf4j), as well as logback-classic (which also includes core). However, you’re excluding some dependencies which are not needed for logback. Change them if you need (specially janino).

Step #2: Declare the java.util.logging Bridge

Simply copy the contents from logging.properties into your project.

Step #3: Modify zero.config as you need

In particular, the /config/logging/levels setting. The one declared is set as the root appender. But the syntax is “logger” : “level”, where you put the desired logging levels.

The one declared in the file is pretty verbose, which may be undesirable. I use those settings:

/config/logging/levels += {
  "*" : "ALL",
  "zero.network" : "OFF",
  "zero.core.context.zones.UserZoneHandler" : "INFO"
}

Step #4: Logback

Declare a logback.xml file. The enclosed one should work with lilith. You can also use logback’s Eclipse Plug-In instead.

Step #5: Lilith

Open, Unpack, Run.

Step #6: The result

Here is the result, in all of its glory!

Beyond logback and java.util.logging: commons-logging and log4j

You can also declare the compatible counterparts for integrating commons-logging and log4j into the slf4j/logback combo as well. Check the slf4j web site for more information.