Definition of ‘Convention over Configuration’

The words ‘Convention over Configuration’ are often bandied about in the programming world these days and I suspect that the idea has largely grown out of some of the complexities and muddles that have been created with XML configuration files.

As a ‘Convention over Configuration’ example, take the wine search scenario that I’ve often used in previous blogs. If I wrote a Wines class that represented a collection of wines then it’s associated database table should also be called wines and not, for example, fermented_grape_juice. I could then write any handling or client software so that if it came across a class called Wines it would automatically assume the name associated database table.

Using the Spring 3 ConverterFactory Interface

Yesterday, I mentioned that the Guys at Spring have come up with a whole new way of doing type conversion that supersedes the property editor support mechanism. This is based on the org.springframework.core.convert package and also I demonstrated how to implement the Converter interface and wire it in with your Spring beans. I also said that it offers additional functionality to the property editor support method and this comes in the form of the ConverterFactory, GenericConverter, and ConditionalGenericConverter interfaces. The Spring documentation briefly details these extra interfaces and how to implement them.

Using the Spring 3 Converter Interface

Yesterday’s blog covered Spring’s older property editor based conversion mechanism. Spring 3 introduces the new org.springframework.core.convert package that provides a complete conversion system, which offers much more functionality than previously available. This blog reimplements yesterday’s idea of regular expression conversion using the Converter interface; a fundamental interface of the new mechanism.

Writing a Custom Property Editor in Spring

Spring’s XML configuration file specifies the beans you wire together to create your application's context. When building your application context Spring, behind the scenes, is busy converting the property values in your XML file, written as Strings, into the correct type required by your bean and it does this using a set of built in property editors. A property editor is an Adaptor class that converts a String value in your XML file into the type required by your bean. For example, given the following bean setter:

Bad Habits with the equals() Method

I have this really bad habit, it’s something I know I shouldn't do, so this blog is to formally document my failing in the hope that I will change. This bad habit concerns the Java if statement and its use with the equals() method. Like me, most people, when comparing a string variable with a string constant would probably write something straight forward like this:

The Annotation Paradigm Shift

One of the current paradigm shifts in the Java world is to update existing APIs that were originally based on inheritance and replace them with much the same API only this time based on annotations.

For example, EJB 2.x used inheritance,

Discover from which JAR File your class is being loaded

A trick often used by certain organisations is to bundle up the Open Source project code on which their proprietary code depends into their own set of randomly named jar files and then to ship them with their products. The guys at BEA / Oracle are guilty of this practise and the upside is that it ensures that the classes used by their product are available and that they don’t get any ClassNotFoundExceptions. The downside to this is that it can lead to mix ups in your code with completing JAR files on your classpath, and possibly competing versions of the same class leading weird bugs.

Applying the @Interceptors Annotation to EJB3 Beans

One of the new features of EJB3 is the ability to apply simplistic Aspect Oriented Programming (AOP) to your beans. This is achieved using the @Interceptors and @AroundInvoke annotations. I’ve called this ‘simplistic AOP’ not to deride it, but to compliment it. AOP can be a very complex topic, and if you only want to implement some simple functionality, like logging for example, then you need a simple tool to do it.

There are two steps to implementing interceptors,

Tag Lib Imports for JSPs

Yesterday I mentioned that I favoured a mixture of different JSP tag libraries, which has come about for no other reason than convenience, which were Spring, JSTL and Struts. Having said that I thought about why I use them and the features I use from each one.

Accessing Spring Resource Bundles from your JSPs

Yesterday’s blog demonstrated how to create and load a set of multi-lingual property file that you can use to internationalise your application. Today’s short blog expands this idea and demonstrates how to access property file values from within your web-apps JSP pages.

The usual way to achieve this is to use JSP tag-libraries. There are many flavours of tag-lib around that duplicate much of the same functionality. My preferred flavours are: struts, JSTL and the Spring tag-libs and it’s the Spring tag lib that I’m using to read property file values.

The first step in using a tag-lib is to add an import line,

Using Spring, ResourceBundles and Locales

Yesterday’s blog covered the Locale class and talked about determining what locales your JVM supports. Today’s bog moves on to how you make use of this information by loading locale specific property files into your Spring application.

When internationalizing your application, it’s common practice to create a property file containing all your presentation strings for each locale you support together with an additional file for those locales that you don’t support.

Spring and the JDK uses the name of your property files to determine their locale. The file name format is:

Listing Locale Information

In writing a global application - if there is such a thing - you’ll often need to add locale specific information. From a Java perspective, a locale is an arbitrary combination of language and country information held in several different ways. This can then be used as a key to describe a whole bunch of other information such as number formatting, currency details and dates and times.

Is the Spring Validator mechanism as friendly as it could be?

When I first came across the Spring validator classes in October 2006, I thought at the time that they weren’t particular clear. They seem fit into that realm of programming where everyone just copies what other people have done without understanding what’s going on and it all works, which is how I’ve seem them used. I guess that today it’d be called Cargo Cult programming. As you know from my previous blog, ValidationUtils will validate your target object without any obvious reference to it, which to me is confusing. You also know that you can pass null in to the Validator.validate() method for the target object, but again there’s no explanation why.

The Spring Validator Interface and Other Animals

An important part of any application is validating your user’s input and the bitter experience of spending hours debugging code that’s failed owing to bad data only serves to underline how crucial this is.

You should virtually always perform user validation at the presentation level and a top-tip is to always factor your validation code into a distinct set of objects and to avoid interweaving it in with

The Difference Between JSON and XML

A few days ago I did a blog Comparing XML and JSON. Today I will be illustrating the difference between JSON and XML using a simple coding example. So, straight to the point: XML is human-readable data interchange specified in a document format, whilst JSON is human-readable data interchange data format.

Using Environment Variables

Java SE 5 re-introduced the idea of allowing Java programs to get at a system's environment variables (I seem to remember that you could do this in the old days and that is was removed for 'non-portability' reasons).

Environment variables are accessed using the System.getEnv() method, which comes in two flavours:

Maven POM Settings for JSON APIs

Having talked about JSON and XML yesterday, I mentioned that there are a number of successful APIs available for both data interchange systems. The two APIs I’ve used for JSON are JSON in Java available from the JSON website and the JSON-Simple API from Google.

Comparing XML and JSON

There seem to have been, at various times, some argument about which open standard for human-readable data interchange is best: JSON or XML. This blog takes a look at these two standards and compares the two,

Using Spring's DisposableBean Interface and a Shutdown Hook in Life-Cycle Management

A few days ago I demonstrated the Runtime class and covered the concept of shutdown hooks to ensure that you can cleanly tidy up external resources when your JVM closes down.

As part of the Spring context life-cycle, it’s pretty important to ensure that your Spring beans close down correctly, especially if they access external resources, and this is where the JDK’s shutdown hooks comes in handy.

Loading Resources Using Spring’s ApplicationContext

Using the ApplicationContext, the guys at Spring provide a uniform way for your application to access various types of resources. These may be a file on the file system or on the classpath or something more remote on the Internet.

Reading and Writing Property Files

Your application will usually need some configuration data that can be set-up prior to run-time and determines how your application runs. A common method for achieving this is to use a one or more property files and these are usually read and written using the Properties class.

Using the JDK’s Runtime Class

“Every Java application has a single instance of class Runtime that allows the application to interface with the environment in which the application is running” is the brief JavaDoc entry for the JDK’s Runtime class, which, if you examine the methods it contains, doesn’t really cover what this class does.

Implementing Spring's FactoryBean Interface

There are times, and not many of them, when Spring cannot load an object in to its context. This is usually the case then the object you’re trying to build has a private constructor and a static factory method (which by convention should be called getInstance()) and cannot be instantiated by simply calling new.

Spring's Application Context Event System

Spring provides a simple and lightweight publish/subscribe or Observer mechanism built around the ApplicationContext. This is a synchronous mechanism in that the event listener code is called during the call to the publishing code.

If you’ve seen this before, you may not know that this system has been updated in the Spring 3 release to use Generics.

Using Spring's ApplicationContextAware Interface

I’ve been trying to think of reasons why you shouldn’t widely use Spring’s ApplicationContextAware interface when constructing your Spring beans. On the surface it seems like rather a bad idea, but with the release of Spring 3, my last reservation has disappeared.

Using Spring's BeanNameAware Interface

Although it’s not a good idea to rely on the BeanNameAware as it adds a “potentially brittle dependence on external configuration”, it is a useful debugging feature especially in the situation where you need to instantiate a number of beans using the same class with each configured in a different way.

Prefer Injecting EJBs via Setter Methods

If you read many of the EJB3 texts you’ll see that they advise you to use the @EJB annotation to inject one ejb into another. This is all good and fine as in a deployment situation the container will neatly inject one bean into another, but, and here’s the problem, all the books and info that I can find on the Internet always recommend that you annotate your injected instance variable. For example, in yesterday’s blog I defined a very simple User ejb and if we use the recommended method for injecting it into another ejb, then we’d annotate our other ejb’s instance variable like this:

EJB3 Stateless Session Bean Annotations

Creating a Stateless EJB using EJB3’s annotations is very simple. Just in case you can’t remember this is how to annotate your java code to create a simple User bean.

Implementing the Observer Pattern using Composition

When I previously discussed the Observer pattern I recommended following Joshua Bloch’s advice and “favor composition over inheritance” and suggested that the JDK’s implementation of the Observer, Observable, though convenient, was somewhat flawed. This blog demonstrates how to implement the Observer pattern using composition. The benefit of using this technique is that it clearly upholds the single responsibility principle broken in several places by my earlier news server examples.

Stateful Session Beans and the @Remove Annotation

There’s not a lot you can really say about Stateful Session Beans except that I’ve never seen them used in large systems owing to the overhead of maintaining a bean in memory for every client and when you’re processing thousands of client requests per second then that’s a lot of memory.