Developing Software

Using VirtualBox on Ubuntu 11.10

2011-11-11T10:06:00.000+01:00

Ubuntu is my regular development environment and to test webapps on Internet Explorer, I use Windows running in VirtualBox. Installing VirtualBox is easy, since you can get it from the Ubuntu Software Center.

To make it really useful, you should install Guest Additions. This enables copy/paste between Ubuntu and Windows, and easy transfer of file by mounting a Ubuntu folder into Windows. You should be able to install Guest Additions by selecting the Devices/Install Guest Additions. However, I get an error message:

Failed to download the VirtualBox Guest Additions CD image from http://dlc.sun.com.edgesuite.net/virtualbox/4.1.2_Ubuntu/VBoxGuestAdditions_4.1.2_Ubuntu.iso.
Error downloading http://dlc.sun.com.edgesuite.net/virtualbox/4.1.2_Ubuntu/VBoxGuestAdditions_4.1.2_Ubuntu.iso - server replied: Not Found

Apparently, the ISO used to be available from SUN, and is probably shutdown after the Oracle merger. After some googling, I found that you can download the ISO manually here:

http://download.virtualbox.org/virtualbox

After downloading, just mount this ISO as a CD in the VirtualBox settings, boot up Windows and startup the installation yourself. After that, copy/paste and mounting host folders should work.

Add Eclipse to Ubuntu Unity lancher

2011-11-07T19:49:00.000+01:00

Just like many other users of Ubuntu, I upgraded a few weeks ago to Ubuntu 11.10 "Oneiric Ocelot". Although the new Unity launcher takes a little time to get used to and has a few quirks, I still like it overall. It takes minimal amount of precious screen real estate and I find the use of the "Windows key" to start applications and find files very productive.

As a software developer I use Eclipse and I like to install some other tools manually under my home directory somewhere.

Add Eclipse to Launcher

To startup Eclipse, I just used the file manager and double clicked on the Eclipse executable. This gets tiresome really quickly. To integrate my self-installed Eclipse into the Unity launcher, you can create a configuration file that will tell the launcher how to startup a custom application like Eclipse.

Create a file with this contents and change the paths to where you installed Eclipse:

[Desktop Entry]
Comment=Eclipse JEE
Exec=/home/koert/software/eclipse-indigo-jee/eclipse
Icon=/home/koert/software/eclipse-indigo-jee/icon.xpm
Name=Eclipse JEE
Path=/home/koert/software/eclipse-indigo-jee
Type=Application
Terminal=false

Save this file as Eclipse.desktop in the .local/share/applications directory in your home directory.

Now, when you want to startup Eclipse, use the launcher (press the windows button) and enter Eclipse. The launcher should display the Eclipse icon, which you can use to start Eclipse. You will see the icon in the dock and you can keep this in the dock.

Start with specific workspace

When you use multiple workspaces, you can choose the workspace when Eclipse starts up by configuring items on the icon so that you can start a specific workspace.

You can add Shortcut Group items, which you must add to the X-Ayatana-Desktop-Shortcuts property.

This is an example with an option to choose a workspace and two options with specific workspaces:

[Desktop Entry]
Comment=Eclipse JEE
Exec=/home/koert/software/eclipse-indigo-jee/eclipse
Icon=/home/koert/software/eclipse-indigo-jee/icon.xpm
Name=Eclipse JEE
Path=/home/koert/software/eclipse-indigo-jee
Type=Application
Terminal=false
X-Ayatana-Desktop-Shortcuts=ChooseWorkspace;Workspace1;Workspace2

[ChooseWorkspace Shortcut Group]
Name=Choose workspace
Exec=/home/koert/software/eclipse-indigo-jee/eclipse
TargetEnvironment=Unity

[Workspace1 Shortcut Group]
Name=Privilege trunk
Exec=/home/koert/software/eclipse-indigo-jee/eclipse -name "Trunk" -data /home/koert/project/pretium/workspace
TargetEnvironment=Unity

[Workspace2 Shortcut Group]
Name=Privilege branche
Exec=/home/koert/software/eclipse-indigo-jee/eclipse -name "Branch" -data /home/koert/project/pretium/workspaces/branch-prod
TargetEnvironment=Unity

This saves me a little bit of time to startup Eclipse in the workspace that I want.

Quickly update your project version with Maven

2011-09-07T09:23:00.002+02:00

When you want to update the version of your project, you can edit the pom.xml file and change the version by hand. When you have a project with multiple sub projects, this is time consuming and error prone.
Maven has a very useful utility to quickly update the version of your project, you can just run this Maven command:

mvn versions:set -DnewVersion=1.2.0-SNAPSHOT

This will update the version of your current project and its sub projects to "1.2.0-SNAPSHOT". This will save the previous version in backup files so you can revert back with this command:

mvn versions:revert

If you are happy with the results and want to get rid of the backup files, just do a commit with:

mvn versions:commit

Using GIT as SubVersion (SVN) client

2011-05-12T15:33:00.000+02:00

Install git-svn in Ubuntu

All git-* commands are implemented in Ubuntu with the git command: 'git-svn' is in Ubuntu 'git svn', notice the space.

Checkout

Do a checkout from SVN with

git svn clone -s -r [revision] [SVN URL] [new directory]

The [SVN URL] is the root of your SVN repository, the remote directory that contains your trunk, tags and branches subdirectories. The [revision] is the SVN revision number from which you want to retrieve history from. You may want to limit the history, because it takes time to retrieve all of the history from SVN. Example:

git svn clone -s -r 198 https://nextaction.googlecode.com/svn nextaction

Update from SVN

To update your local files from SVN, execute:

git svn rebase

If the update refuses to pull the changes from SVN and displays a message with "needs update", you probably made changes that you have not commited yet. Apparently, you must commit your changes locally first

Commit to GIT

When you make changes to your local files, you can commit them with:

git commit -a -m "Commit message"

Commit to SVN

This will only commit changes to your local GIT repository, to commit (or "push" in the GIT jargon) to SVN, use:

git svn dcommit

Creating a reusable layout component in Android

2011-03-29T18:39:00.002+02:00

Let us say that we want to use a common layout in several places in your user interface. Something like a box with a label and value text view vertically layed out. The application uses the same label/value TextView in 3 different places.

This is the common label/value layout component (file: layout/dashboard_item.xml):

<LinearLayout 
  xmlns:android="http://schemas.android.com/apk/res/android"
  android:orientation="vertical"
  android:layout_width="fill_parent"
  android:layout_height="fill_parent">
  
     <TextView android:id="@+id/label"
         android:layout_width="fill_parent"
         android:layout_height="wrap_content"
         android:layout_weight="0"
         android:gravity="center_horizontal"
         style="@style/label"
     />
     <TextView android:id="@+id/value"
         android:layout_width="fill_parent"
         android:layout_height="fill_parent"
         android:layout_weight="1"
         android:gravity="center"
         style="@style/output"
     />
</LinearLayout>

We want to use it in a screen definition (file: layout/home.xml):

<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
      xmlns:labelValue="http://schemas.android.com/apk/res/net.kazed.sailor"
      android:layout_width="fill_parent"
      android:layout_height="fill_parent"
      android:orientation="vertical"
      style="@style/screen"
      >

    <net.kazed.sailor.view.LabelValueItem android:id="@+id/vmg"
       android:layout_width="fill_parent"
       android:layout_height="fill_parent"
       android:layout_weight="1"
       labelValue:label="@string/vmg"
    />
    
   </LinearLayout>
</RelativeLayout>

Here we reuse the label/value custom component implemented by the LabelValueItem class. This component has one custom attribute: "labelValue:label". Notice that this attribute has a namespace that corresponds with the package name of the Android application (defined in AndroidManifest.xml). The component class retrieves the value of the custom attribute and uses it to set the text of the label TextView (file: src/net/kazed/sailor/view/LabelValueItem.java):

public class LabelValueItem extends LinearLayout {
   
   public LabelValueItem(final Context context, final AttributeSet attrs) {
      super(context, attrs);
      LayoutInflater.from(context).inflate(R.layout.dashboard_item, this, true);

      TypedArray array = context.obtainStyledAttributes(attrs, R.styleable.labelValue, 0, 0);

      TextView label = (TextView) findViewById(R.id.label);
      String labelText = array.getString(R.styleable.labelValue_label);
      if (labelText != null) {
         label.setText(labelText);
      }

      array.recycle();
   }

}

To make it all work, the application must define the custom attribute (file: values/attr.xml):

<?xml version="1.0" encoding="utf-8"?>
<resources>
   <declare-styleable name="labelValue">
      <attr name="label" format="string" />
   </declare-styleable>
</resources>

Error messages for required fields in JSF 1.2

2011-02-21T13:19:00.001+01:00

JSF 1.1

When you have required fields in your JSF page, you simple add the required="true" attribute to the inputField and the user will get error message when user the field the field blank.

<h:inputText id="accountnumber" value="#{accountSetting.accountNumber}"
  required="true" />

This is all great, since we don't have to do much as a developer. However, the user gets an ugly error message: "accountForm:accountnumber: Validation Error: Value is required." This message is customizable by overriding this message in your message bundle and is pretty limited in how customized you want it to be.

JSF 1.2

JSF 1.2 and later makes it easier to create custom error messages for required fields, just add the requiredMessage attribute:

<h:inputText id="accountnumber" value="#{accountSetting.accountNumber}"
  required="true" requiredMessage="Account number is required" />

When the user has forgotten to enter something in this field, the JSF framework will display the error message supplied with the requiredMessage attribute. To supply translations for different languages, you can put the message in a resource bundle. Note that you must configure this resource bundle in faces-config.xml like this:

<application>
  <!-- ... -->
  <resource-bundle>
    <base-name>com.example.messages</base-name>
  <var>bundle</var>
  </resource-bundle>
</application>

This makes it possible to use the configured variable "bundle" anywhere in your pages, including the requiredMessage:

<h:inputText id="accountnumber" value="#{accountSetting.accountNumber}"
  required="true" requiredMessage="#{bundle.error_required_accountNumber}" />

I have found that the old way of using the loadBundle JSF component does not work with requiredMessage. The configured resource-bundle in faces-config.xml is much neater anyway.

Getting started with GIT

2011-01-03T12:06:00.002+01:00

I recently started working on a new project and decided to try out the source repository GIT. As a long time user of CVS and Subversion (SVN), these distributed repositories take a little time getting used to.
As long as you use it yourself in a one man project, a distributed repository is almost the same as CVS and SVN. You check code out, make modifications and commit. The major difference is that you then "push" your commits to another repository, usually a remote server.

Create a local repository

To get started, after installing GIT, you can create a repository with the "init" command.

cd /path/to/repository
git init

Make modifications

Just like CVS and SVN, you can add/modify/delete files and commit them.

git add readme.txt
git commit -a -m "added readme text"

Note that this commit is stored locally, it is not committed to a central server.

Copy a repository

You can create a copy of a local repository with the "clone" command. This way you can locally make a branch.

cd /path/to/workspace
git clone /path/to/repository

Shareable repository

To create a sort of "central" repository like CVS or SVN, you can create a shareable repository with the "init" command. Do this on your server.

cd /path/to/repository
git init --bare --shared

Checkout with SSH

I use SSH to "checkout" from the remote repository, do this on your client.

cd /path/to/workspace
git clone ssh://myserver/path/to/repository

This makes a copy of the remote repository to my local workspace. Here I can make modifications and commit them. GIT will store your commit locally until you "push" this to the central repository.

git add readme.txt
git commit -a -m "added readme text"
git push origin master

This last command will update the remote repository with your commits.

Flexible layout with RelativeLayout in Android

2010-11-26T11:25:00.002+01:00

I often create a layout for my Android applications with a list and horizontal row of buttons on the bottom. Considering that Android devices come in very different sizes, you want to make this layout flexible so that the list takes up the entire area above the row of buttons on the bottom.

You could do this with a LinearLayout and use layout_weight. This often does not behave the way I want to because the LinearLayout is quite limited. I found an easier way to use a RelativeLayout, see the example:

<?xml version="1.0" encoding="utf-8"?>
<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
      android:layout_width="fill_parent"
      android:layout_height="fill_parent"
      android:orientation="vertical">
    
     <LinearLayout android:id="@+id/button_bar"
          android:orientation="horizontal"
          android:layout_width="fill_parent"
          android:layout_height="wrap_content"
          android:layout_alignParentBottom="true"
          >

        <Button android:id="@+id/add_task_context_button"
             android:layout_width="fill_parent"
             android:layout_height="wrap_content"
             android:layout_weight="1"
             android:text="@string/task_context_add_button_title"
             />
        <Button android:id="@+id/cancel_button"
             android:layout_width="fill_parent"
             android:layout_height="wrap_content"
             android:layout_weight="1"
             android:text="@string/cancel_button_title"
             />
        <Button android:id="@+id/ok_button"
             android:layout_width="fill_parent"
             android:layout_height="wrap_content"
             android:layout_weight="1"
             android:text="@string/ok_button_title"
             />
     </LinearLayout>

    <ListView android:id="@+id/android:list"
              android:layout_width="fill_parent" 
              android:layout_height="fill_parent"
              android:layout_alignParentTop="true"
              android:layout_above="@id/button_bar"
              android:drawSelectorOnTop="false"
              style="@style/list"  
              />

    <TextView android:id="@+id/android:empty"
              android:layout_width="fill_parent"
              android:layout_height="wrap_content"
              android:layout_alignParentTop="true"
              android:text="@string/no_task_contexts"
              style="@style/label"                
              android:padding="10px"
              />
              

</RelativeLayout>

When you use a RelativeLayout, pay attention to the order of components. Because you specify where components are positioned relative to the parent's borders and other components.

To make my layout work, I first specify the horizontal row of buttons first (button_bar), contained in a LinearLayout with android:layout_alignParentBottom="true". When you position the list on the top with android:layout_alignParentTop="true", you also attach the bottom of the list with the top of the button row with android:layout_above="@id/button_bar". This way, the RelativeLayout will stretch the list between the top of the parent and the top of the button_bar.

Handling portrait/landscape switch in Android

2010-03-02T09:48:00.000+01:00

When you develop an Android application, you will notice that when the user changes the orientation of the device, the UI framework will recreate the current screen layout with the corresponding UI objects. The framework calls these methods of the current activity: onPause, onStop, onDestroy, and then onCreate, onStart, onResume to display the activity again. The onCreate method of the activity retrieves the data it displays from a database and populates the input fields with the private populateFields method.

public void onCreate(Bundle savedInstanceState) {
  super.onCreate(savedInstanceState);
  /* UI setup here */
          
  Uri itemUri = getIntent().getData();
  if (newRecord) {
    customer = new Customer();
  } else {
    customer = retrieveCustomer(itemUri);
  }

  populateFields(customer);
}

When the user switches orientation, the Android framework will destroy this activity and call onCreate again, which will retrieve the data and populate the input fields. The result is that the user will lose entered data, because this input fields will contain what the activity retrieved from the database. A solution is to store the entered data in the database in the onPause method:

protected void onResume() {
  copyFromInput(customer);
  if (newRecord) {
    saveCustomer(customer);
  } else {
    updateCustomer(customer);
  }

  super.onResume();
}

This solution mostly works and also takes care of automatic saving the entered data when the user uses the "home" button. This may also surprise the user, since the data is saved without the user explicitly asking to save it. A better solution is to use the savedInstanceState parameter that the Android framework passes into the onCreate method. This parameter is null when the user navigates to the activity. When the user changes orientation of the Android device, the framework destroys the activity after saving the contents of the input fields in a Bundle object. When the framework recreates the activity after an orientation change, the savedInstanceState parameter is not null and contains all the data that your application would want save during this change. The Android framework already automatically saves and restores the contents of the input fields, so your application does not need to do this. The thing that your application needs to be aware of is that it should only set the contents of the input fields when the savedInstanceState parameter is null.

public void onCreate(Bundle savedInstanceState) {
  super.onCreate(savedInstanceState);
  /* UI setup here */
          
  Uri itemUri = getIntent().getData();
  if (newRecord) {
    customer = new Customer();
  } else {
    customer = retrieveCustomer(itemUri);
  }
  
  if (savedInstanceState == null) {
    populateFields(fragment);
  }
}

ID design

2010-01-29T10:10:00.004+01:00

We often take the IDs that we use in databases and applications for granted. As long as we can identify a data record with a unique number, everything is great. Recently, I ran into an interesting problem in an existing application. The ID that was used has this format:

ABBBCCC

A = last digit of year
BBB = day number of the year
CCC = sequence number

For example, you could get on 2 february 2009 this ID: 9033012. This would be the twelveth data record of the day.

More digits

Sometimes, the application would generate more than 1000 data records on a day and run out of numbers. In that case the application just add digits to get something like this:

ABBBCCCDDD

A = last digit of year
BBB = day number of the year
CCCDDD = sequence number with additional digits

Example: 9003123456

Perhaps you can sense some trouble here...

Decade trouble

Obviously, you will run into problems after 10 years of using this application. It makes you wonder if the designers of this application have learned anything from the Y2K problems, is storage space really this precious that you cannot spare another 3 bytes?

Length confusion

The fact that the system adds another 3 digits is pretty confusing. Technically, the ID is still unique and valid. Normally we add digits in the front of the number, not in the back of the number. This makes it impossible to sort these IDs in a meaningful way. For example, an ID created on january 1 (9001123456) could have a higher value than an ID created on january 2 (9002001).

Number interpretation

After the year 2010 started, the IDs suddenly started with a "0", like 0003123456 and in some subsystems, this ID is interpreted as a number, which would make it 3123456. Suddenly this ID can collide with an already existing ID from the year 2003.

ID should have no content

When the engineers were trying to solve this problem, they wanted to change the ID generator to just use an Oracle sequence and do away with the year/day nonsense. Because the system has grown rather large and complex over the year, changing the ID generation may cause more problems, because no one is sure that the contents of the ID is not interpreted in same way. It could be that a part of the system is making use of the fact that the ID contains the year and day number.

Conclusion

As you can see, designing an ID can be tricky. Lessons learned:

if you use a year, please use the full year, do not try to save a little bit of storage, it might cost a lot of money later on
avoid meaningful content in the ID to prevent "clever" people from exploiting this, otherwise you can never change the way an ID is generated
allocate enough digits in the ID, the application may live much longer than you think
keep it simple, use a sequence generator

Using a Syslog appender in log4j

2009-12-15T13:59:00.017+01:00

The log4j framework has several appenders and one of them is the SyslogAppender. This appender lets you append log messages to syslog, a popular logging service on Unix and Linux. To use this appender, just add this to your log4j.xml configuration file:

<appender name="syslog" class="org.apache.log4j.net.SyslogAppender">
  <param name="Facility" value="USER"/>
  <param name="SyslogHost" value="localhost"/>
  <param name="Threshold" value="WARN"/>
  <layout class="org.apache.log4j.PatternLayout">
    <param name="ConversionPattern" value="%d{MMM dd HH:mm:ss} MYAPP: %-5p %m%n"/>
  </layout>
</appender>

You can use the usual log4j API to log messages:

public class AppWithStandardLogger {
  private static final Logger logger = Logger.getLogger(AppWithStandardLogger.class);

  public void someMethod() {
    try {
       // ...
    } catch (ConnectionException e) {
       logger.fatal("#Failed to connect to database", e);
    }
  }
}

Severity level mapping

If you use logger.fatal(), the standard log4j syslog appender will log this message with the highest syslog severity, which is level 0, "emerg". This level is usually reserved for the most urgent operating system related messages and on most Unix systems will print the message on the terminal session of every logged in user. For most applications, this is probably not what you want. If an application encounters a fatal error, it should log the message as a lower level like "critical", level 2. You can do this by implementing an appender which overrides the "append" method:

import org.apache.log4j.Level;
import org.apache.log4j.spi.LoggingEvent;

/**
 * Appender that fixes level mapping to syslog.
 */
public class SyslogAppender extends org.apache.log4j.net.SyslogAppender {
 @Override
 public void append(LoggingEvent event) {
  Level log4jLevel = event.getLevel();
  Level newLevel = null;
  if (log4jLevel.equals(Level.FATAL)) {
   newLevel = SyslogLevel.FATAL;
  } else {
   newLevel = event.getLevel();
  }
  LoggingEvent newLoggingEvent = new LoggingEvent(
    event.getFQNOfLoggerClass(), event.getLogger(), event.getTimeStamp(), newLevel,
    event.getMessage(), event.getThreadName(), event.getThrowableInformation(),
    event.getNDC(), event.getLocationInformation(), event.getProperties());
  super.append(newLoggingEvent);
 }

 /**
  * Fix for level mapping - log4j "fatal" is mapped to syslog "critical".
  */
 public static class SyslogLevel extends Level {
  private static final long serialVersionUID = 1L;
  public static final Level FATAL = new SyslogLevel(FATAL_INT, "FATAL", 2);
  
  protected SyslogLevel(int level, String levelStr, int syslogEquivalent) {
   super(level, levelStr, syslogEquivalent);
  }
 }
}

This custom appender will map the log4j "fatal" messages to syslog "critical" (level 2) severity.

Stack traces

With log4j you can also log the stack trace when you pass the exception as extra parameter. In my work the syslog system will pass the messages through to Tivoli and this monitoring system should not receive stack traces. With a custom log4j PatternLayout, we can filter out stack traces by overriding the ignoresThrowable() method:

import org.apache.log4j.PatternLayout;

/**
 * Layout that prevents stack traces to be logged.
 */
public class NoStackTracePatternLayout extends PatternLayout {
 @Override
 public boolean ignoresThrowable() {
  return false;
 }
}

Putting it together

To use both the custom Appender and Layout, use this configuration:

    <appender name="syslog" class="net.kazed.log4j.SyslogAppender">
     <param name="Facility" value="USER"/>
     <param name="SyslogHost" value="localhost"/>
     <param name="Threshold" value="WARN"/>
     <layout class="net.kazed.log4j.NoStackTracePatternLayout">
       <param name="ConversionPattern" value="%d{MMM dd HH:mm:ss} MYAPP: %-5p %m%n"/>
     </layout>
    </appender>

The code is unchanged, we only changed the configuration.

Using a named syslog logger

If you want to have control over what and how the application logs to the log file and syslog, you could configure a separate logger with a name:

    <logger name="monitoring">
      <level value="WARN" />
      <appender-ref ref="syslog" />
    </logger>

In the code, you refer to the "monitoring" logger and you can log a different message to the monitoring system:

public class AppWithNamedLogger {
 private static final Logger logger = Logger.getLogger(AppWithNamedLogger.class);
 private static final Logger monitorLogger = Logger.getLogger("monitoring");
 
    public void someMethod() {
     try {
   throw new ConnectionException();
   // ...
  } catch (ConnectionException e) {
   logger.fatal("Failed to connect to database", e);
   monitorLogger.error("Failure to connect to database");
  }
 }
}

As you can see, we must change the code and add a second logger and use this to log explicitly to the monitoring system.

Conclusion

When logging to a monitoring system you can avoid changes to the source code by changing the configuration and add the monitoring logger. The standard syslog appender implementation maps the log4j fatal to syslog emerg, which level is too high for most Unix/Linux installations. A custom appender can fix this mapping. To avoid logging stack traces, you can implement custom Layout. With a named logger you can log special messages explicitly to the monitoring system. This requires changing the code.

Use Enumeration instead of Constant

2007-12-18T15:37:00.000+01:00

Using Enumeration instead of Constant

I think we all regularly use integer or String status codes or other magic numbers in our Java code. And we probably also define (static final) constants to make these constants known to the users of our code. While this works fine for small projects, I noticed, when working on larger scale project, that I spent a considerable amount of time trying to find which constants I needed.

In many applications I encounter, this kind of API for a service is quite common:

public static final String DOCUMENT_TYPE_TEXT = "text";
public static final String DOCUMENT_TYPE_SPREADSHEET = "spreadsheet";
List findDocuments(String documentType);

In the above API, it is pretty obvious that I should use the listed constants as the documentType parameter. However, I have seen many cases where the constants are defined in some other place and sometimes an archeology expedition was needed to find the correct values to use. I also have the freedom to pass any String that I didn't get from a constant and just hardcoded. Because of this freedom, the service must check if the passed in documentType parameter is valid (who knows what the user passes to the service).

To make the API more watertight, we could require the user to supply a constant of a class that we define ourselves:

List findDocuments(DocumentType documentType);

This is the DocumentType class:

public class DocumentType {
  public static final DocumentType TEXT = new DocumentType("text");
  public static final DocumentType SPREADSHEET = new DocumentType("spreadsheet");

  private String name;

  private DocumentType(String name) {
    this.name= name;
  }

  public String getName() {
    return name;
  }
}

Apache common lang Enum

In the example above we still need to implement the equals() and hashCode() methods to make it possible to check which documentType the user passed to the service. The easy way is to subclass from the Apache common lang Enum class, this superclass implements the boring stuff (equals, hashCode, compareTo, getName):

import org.apache.commons.lang.enums.Enum;
public class DocumentType extends Enum {
   public static final DocumentType TEXT = new DocumentType("text");
   public static final DocumentType SPREADSHEET = new DocumentType("spreadsheet");
 
  private DocumentType(String name) {
     super(name);
   }
}

This solution works well if you're stuck with Java 1.4. However, if you work on a project that runs on Java 5 or later, you should consider the build-in enum types.

Migrate to Java 5 enum

The Java language designers have added the enum type in Java 5 to make it easier to define a type-safe constant. The DocumentType enumeration becomes very simple:

public enum DocumentType {
    TEXT,
    SPREADSHEET;
}

The code of our service runs unchanged, since the equals method of an enum behaves the same way. In the case you need to interface with legacy code that gets a string from a database or property file to create the corresponding constant, you can add a String as private member of the enum:

public enum DocumentType {
    TEXT("text"),
    SPREADSHEET("spreadsheet");
    
    private final String name;
    
    DocumentType(String name) {
        this.name = name;
    }

    public String getName() {
        return name;
    }
}

Conclusion

Using strong types instead of Strings or integers has these advantages:

the interface of your objects is much clearer and less ambiguous,
you get code completion in your IDE (no need to "hunt for constants"),
easier refactoring by your IDE,
type safety - your client cannot supply invalid String or integer constants.

Spring bean configuration validation

2007-11-19T20:05:00.000+01:00

If you enthousiastically use Spring like me and dutifully inject every dependency in your beans with Spring's XML configuration, you have probably encountered the situation that you forgot to inject a property and received a NullPointerException from an unexpected place in your code. Wouldn't it be nice to check the configuration of your bean after it is instantiated? Your bean could implement the InitializingBean interface, which would cause the Spring application context to call the afterPropertiesSet method after your bean is instantiated and injected with dependencies. This would make your bean directly dependent on Spring and you probably would not want that.

Attribute "init-method"

A better solution is to call a method of your bean that validates its own configuration with the "init-method" attribute of the bean element in the application context XML:

<bean id="bean1" class="net.kazed.spring.config.validator.ExampleBean1" init-method="validateConfiguration">
 <property name="bean2" ref="bean2"/>
 <property name="bean3" ref="bean3"/>
</bean>

public void validateConfiguration() {
 DependencyAssert.notNull(bean2, "bean2");
 DependencyAssert.notNull(bean3, "bean3");
}

The Spring container will call the "validateConfiguration" method after your bean, in which you can check if all required dependencies are injected. The only thing is that you should not forget to add the "init-method" attribute.

BeanPostProcessor

Since our goal was to catch configuration mistakes, this solution just is not good enough. Fortunately, you can create a post-processor for the Spring container that will examine every created bean after instantiation and dependency injection. By implementing a BeanPostProcessor, you can invoke the validateConfiguration method. To make it nice and intuitive, we can create an interface ValidatableConfiguration with the validateConfiguration method. Interface:

public interface ValidatableConfiguration {
/**
 * Validate the configuration of the object.
 */
void validateConfiguration();
}

ValidatingBeanProcessor:

public class ValidatingBeanProcessor implements BeanPostProcessor {
  public Object postProcessBeforeInitialization(Object bean, String beanName)
   throws BeansException {
   return bean;
  }

  public Object postProcessAfterInitialization(Object bean, String beanName)
   throws BeansException {
   if (bean instanceof ValidatableConfiguration) {
     try {
       ((ValidatableConfiguration) bean).validateConfiguration();
     } catch (DependencyNullException e) {
       throw new ConfigurationValidationException("Configuration of bean '" + beanName
         + "' failed - " + e.getMessage(), e);
     }
   }
   return bean;
  }
}

We just declare the ValidatingBeanProcessor once in the application context, and the container will use it for every created bean:

<bean id="beanValidator" class="net.kazed.spring.config.validator.ValidatingBeanProcessor">

The nice thing is that we only have to make the bean implement the ValidatableConfiguration interface and it will automatically be used to validate the bean whenever you declare it in the application context. Advantages:

Intuitive design - implement interface and it will be validated
No special configuration (except from the one ValidatingBeanProcessor)
Validation is done only once and during instantiation of the application context - it will fail early
Error message is descriptive - no more puzzling NullPointerException

Constructor injection

Traditionally, the Spring team favored setter injection because of more readable configuration. Spring has always also supported constructor injection and recently this has received more attention in the Spring community (see Alef's blog). Constructor injection makes validation incredibly simple: just validate in the constructor.

public ExampleBean1(ExampleBean2 bean2, ExampleBean3 bean3) {
 super();
 DependencyAssert.notNull(bean2, "bean2");
 DependencyAssert.notNull(bean3, "bean3");
 this.bean2 = bean2;
 this.bean3 = bean3;
}

<bean id="bean1c" class="net.kazed.spring.config.validator.ExampleBean1">
 <constructor-arg ref="bean2"/>
 <constructor-arg ref="bean3"/>
</bean>

As you can see, constructor injection is a bit harder to read because the arguments are nameless and depend on the order.

Conclusion

I would prefer to use constructor injection and use (or combine with) setter injection if some dependencies are optional. The BeanPostProcessor is very useful because it is non-obtrusive and automatically validates the configuration of a bean when it implements an interface that you define yourself and can be a logical part of your domain model. Retrieve here the source code of these examples.

Create your own JSF variable resolver

2007-10-26T11:07:00.000+02:00

The system I am working on, uses a singleton service factory (that uses Spring to configure the services) to lookup service instances. The JSF backing beans use these services to perform business operations and need to lookup the services with the central service locator. This is quite straightforward and unfortunately less straightforward when you want to unit test it: it would be a lot easier to inject the services into the backing beans like we are used to in Spring. Spring has a variable resolver that makes it possible to inject Spring managed beans defined in WEB-INF/applicationContext.xml into JSF managed beans. For various reasons the system I am working on cannot put the services in application context of the web application (service instances must be shared between multiple web applications on the server). To make the same sort of injection possible, I created a JSF variable resolver that will lookup the desired service in the global service locator.

public class ServiceLocatorVariableResolver extends VariableResolver {

private VariableResolver originalVariableResolver;
private ServiceLocator serviceLocator;

/**
* Constructor.
* @param originalVariableResolver Original JSF variable resolver.
*/
public ServiceLocatorVariableResolver(VariableResolver originalVariableResolver) {
   this.originalVariableResolver = originalVariableResolver;
}

/**
* {@inheritDoc}
*/
public Object resolveVariable(FacesContext context, String name) throws EvaluationException {
   Object result = null;
   result = originalVariableResolver.resolveVariable(context, name);
   if (result == null) {
     if (serviceLocator == null) {
         serviceLocator = ServiceLocatorFactory.getInstance().getLocator();
     }
     try {
         result = serviceLocator.getBean(name);
     } catch (NoSuchBeanDefinitionException e) {
         // ignore exception - bean not found
     }
   }
   return result;
}
}

As you can see, creating a variable resolver is quite straightforward and make dependency injection possible, even if you use an old fashioned service locator. Unit testing becomes a lot easier this way.

Developing Software

Using VirtualBox on Ubuntu 11.10

Add Eclipse to Ubuntu Unity lancher

Add Eclipse to Launcher

Start with specific workspace

Quickly update your project version with Maven

Using GIT as SubVersion (SVN) client

Install git-svn in Ubuntu

Checkout

Update from SVN

Commit to GIT

Commit to SVN

Creating a reusable layout component in Android

Error messages for required fields in JSF 1.2

JSF 1.1

JSF 1.2

Getting started with GIT

Create a local repository

Make modifications

Copy a repository

Shareable repository

Checkout with SSH

See also

Flexible layout with RelativeLayout in Android

Handling portrait/landscape switch in Android

ID design

More digits

Decade trouble

Length confusion

Number interpretation

ID should have no content

Conclusion

Using a Syslog appender in log4j

Severity level mapping

Stack traces

Putting it together

Using a named syslog logger

Conclusion

Use Enumeration instead of Constant

Using Enumeration instead of Constant

Apache common lang Enum

Migrate to Java 5 enum

Conclusion

Spring bean configuration validation

Attribute "init-method"

BeanPostProcessor

Constructor injection

Conclusion

Create your own JSF variable resolver