Total Pageviews

Thursday, April 19, 2012

Logging in Java: Switching to logback and slf4j

log4j was and maybe still is the de facto standard when it comes to logging in Java applications.
Sun's solution with the internal JDK logging could not be enforced across the board. The reasons for this are certainly the lack of configurability and flexibility. For simple projects the JDK logging is certainly a solution, but not for enterprise applications.

Now, in addition to log4j a new implementation that is more powerful, faster and more flexible than log4j has entered the market: logback. Ok, in fact logback was started in 2006, but version 1.0 was released in Nov. 2011.

logback has been created as a successor to log4j by the same developer and is now available after many years of testing and development in a version 1.0 (current version is 1.0.1). To avoid misunderstandings due to the small version number it should be said that logback is already in use for years in business and the version number does not reflect in any case a statement about the stability or functionality.

logback provides several advantages over log4j. Among other things:
  •      Much faster implementation
  •      Automatic reloading of logging configuration
  •      Better filter
  •      Automatic compression of archived log files
  •      Stack traces with information about the manufacturing Java Package (jar file)
  •      Automatic removal of old log archives

For the developer a switch from log4j to logback is very easy. Just switch a dependency in your Maven POM and you are ready to go:


Thanks to the transitive dependencies you now also have the logging facade slf4j added to your project.
A "Hello World" example using slf4j looks like this:

 package demo;  
 import org.slf4j.Logger;  
 import org.slf4j.LoggerFactory;  
 public class HelloWorld {  
   public static void main(String[] args) {  
    Logger log = LoggerFactory.getLogger(HelloWorld.class);"Hello World");  

All that remains is a configuration file to control log output. 

With log4j it is usually called log4j.xml. With logback it is called logback.xml or logback-test.xml for testing environment.

In Maven projects the file logback.xml must be placed into $PROJECT_HOME/src/main/resources. The file logback-test.xml must be placed into $PROJECT_HOME/src/test/resources. A simple configuration looks like this:

  <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">  
   <!-- encoders are assigned the type  
      ch.qos.logback.classic.encoder.PatternLayoutEncoder by default -->  
    <pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n</pattern>  
  <root level="debug">  
   <appender-ref ref="STDOUT" />  

The complete manual for logback is very detailed and available here.

Wednesday, April 18, 2012

Moving default progress indicator and make it modal in Vaadin

The default progress indicator in Vaadin is displayed at the upper right corner of your web application. Sometimes this is not the best location, especially if you want your users not to miss this little image. So just place the progress indicator into the centre of the screen.
The progress indicator is by default not modal, so users can still interact with the web application. Maybe this is not what you want and you would like to make the progress indicator modal so users can't interact with the web application during a long running process.
To summarize the goals:
  1. Move default progress indicator from upper right corner to centre
  2. Make indicator modal, so users can't interact during a long running process
The easiest thing to accomplish this is to edit the styles.css file of your Vaadin theme. If you use the standard theme you may want to extend it by creating your own styles.css for your theme.
I use the reindeermods theme so the styles.css example provided below extends exactly that theme.
The minimal styles.css solution to solve the requirements:

 @CHARSET "ISO-8859-1";
 @import url(../reindeermods/styles.css);

 .v-loading-indicator-wait {  
   width: 100%;  
   height: 100%;  
   margin: 0;  
   background-position: 50%;  
   background-color: gray;  
   background-repeat: no-repeat;  
   background-attachment: fixed;   
   opacity: .8;  
   -ms-filter: alpha(opacity=80);  
   filter: alpha(opacity=80);  

This solution was taken from this Vaadin forum post.

Friday, April 13, 2012

How to edit UTF-8 resource properties in Eclipse

Editing resource properties files in Eclipse is easy - as long as you don't need characters beyond the ISO-8859-1 encoding.
Characters that cannot be directly represented in this encoding can be written using Unicode escapes.
I really don't know all Unicode escapes for german umlauts and I don't want to waste my time with those things when editing properties files.

The first solution I tried was to create my properties file with an UTF-8 encoding using Notepad++. This works pretty well as far as you don't touch this file ever again with Eclipse :-(
Any change of the file using Eclipse converts this file back to ISO-8859-1 encoding and native umlauts like "ä" and "ü" will display strangely in your application.

Note: In Eclipse Preferences every encoding setting (Workspace, CSS, HTML, JSP, XML) was set to UTF-8. In this Stackoverflow question someone tried even the option of specifying -Dfile.encoding=UTF-8 in eclipse.ini. Still not working.

BTW, if you prefer creating and maintaining UTF-8 properties files (maybe you don't work with Eclipse or use another IDE/Editor which is capable of editing UTF-8 property files) you have to check out this stackoverflow posting. Both code examples of reading resource bundles in UTF-8 format work like a charm.

For me, this is not an option because I want to stick to Eclipse and I don't want to edit the properties files with a different tool.

What finally really did the trick was the Resource Bundle Plugin for Eclipse mentioned in this stackoverflow answer. The plugin converts native non ISO-8859-1 characters on the fly to Unicode escapes and frees you from typing the Unicode escapes manually.
All in all a pretty good solution and a very handy plugin.

Thursday, April 12, 2012

Adding Vaadin Add-Ons to your Maven managed application

One of the things I really like about Vaadin is the simplicity and the speed when developing the UI with Vaadin. Another great benefit of Vaadin is its Add-On directory where lots of useful add-ons are maintained and provided.

Add-Ons which implement client side UI must be recompiled by the GWT compiler to include them into your app.
To me it was not clear how to do that precisely despite the docs provided here and here.

I found this great blog article describing the necessary steps to use Add-ons with Maven. This is especially useful and described in detail for using Add-Ons which implement client side (JavaScript) code.

To minimize compile time I recommend to use a maven profile as described in the article. This prevents a GWT compilation of the widgetset each time the project is built.

In my case I used version 2.3.0 for GWT and for the gwt-maven-plugin.

Sunday, April 08, 2012

Using Eclipse 3.7 and GlassFish 3.1.2 server runtime plugin under Windows to control GlassFish servers

I installed GlassFish 3.1.2 Open Source Edition on my Windows 7 box and wanted to manage the GlassFish instance from Eclipse 3.7 using the GlassFish server runtime plugin.
I installed the plugin via the eclipse marketplace and found out that the version from the marketplace doesn't support GlassFish 3.1.2.
So I googled around and found out about this blog post describing how to install the GlassFish server runtime plugin properly on Eclipse 3.7. There is also a great stackoverflow question describing the problems with multiple "internal GlassFish servers" each time you start Eclipse after you have installed the server runtime plugin for GlassFish 3.1.2.
The later problem only occurs on Windows machines!