Dummy Files in Unit Tests

(Recovered from my old Blog).

Let’s say that you have an application which accepts a filepath as part of its interface. When unit testing, you may have some dummy files which you use to test the interface.

However, getting the full path of these test files can be a pain.

Assuming that the files are (as per Maven conventions) in /src/test/resources/ then they will be put on the classpath (by default /test-classes/ as part of the build process.

If you’re using Spring, then you can take advantage of that to do the following:

inputFilename now contains the full path to the file, and can be passed into your application as per normal.

Load a CSV file into an ArrayList

(Recovered from my old Blog).

It isn’t hard to write code which iterates through files, cuts them up and loads them into an ArrayList. And if the delimiting character isn’t a comma? No problem, it isn’t hard to add that functionality. And if you want to skip the first set of lines because you’re paginating the file? Easy! And if you want to write some changes back out again – no problem, I can add that feature in no time.

Except it’s already been done. So why waste the time? 🙂

OpenCSV is an easy to use library which you can embed into your applications (Apache License). Then you can simply do something like:

And you’re done. See the OpenCSV homepage for some of the other features.

Custom XStream Converter

(Recovered from my old Blog).

XStream is a great utility for serializing objects to XML – and then back again.

The default XML output is neat enough – albeit a little verbose (using fully qualified class names for example). There are plenty of tutorials available showing how to use XStream aliases to clean up the output (e.g. Manual Tweaking Output).

However, sometimes it is not enough to just tweak and alias – more serious manipulation of the output stream is required. For example, complicated Collection-based objects come out very cumbersome (but generic – which is the point). Luckily, XStream provides a powerful interface for custom generation (A Converter in XStream-speak).

To fully control how an object is serialised, create a new class which implements the Converter interface:

As can be seen above, the canConvert method tells XStream which objects should use this converter. The other two methods are called when converting objects to XML (marshal) or converting XML to objects (unmarshal).

Marshalling the object is achieved by starting and ending Nodes, while populating their attributes and values. So for example:

will iterate through a collection generating the following output:

These patterns can become arbitrarily complex.

Unmarshalling is a little more complicated. XStream will work out which (registered – see later) Converter to use by matching the node to the class (in my head these seems like an extremely difficult task… I’m not sure how XStream has implemented this – maybe I should look into this!) The node (and all children) will be passed to the unmarshal method.

It is up to us to define how the target object is populated from these nodes. Methods are provided to:

Check if the node has children (reader.hasMoreChildren())
Move down to the child level (reader.moveDown())
Move back up to the parent level (reader.moveUp())
The moveUp/Down methods can be called as many times as necessary to walk the tree.

I provide a full example as I couldn’t find many good ones on the net:

Out of completeness, here is the equivalent marshal implementation:

To register the Converter simply add the following line when you instantiate the XStream object:

Log4j and Tomcat issue

(Recovered from my old Blog).

Quick one – I had this issue today so wanted to record it for posterity.

Tomcat can get confused if WEB-INF/lib contains the log4j jar, with initialisation errors such as:

java.lang.ClassNotFoundException: org.apache.log4j.Category

You might not even have directly included it – it might be included via a Maven dependency.

The solution is simple; remove log4j! It’s (often) already included in Tomcat, which is the root cause of the issues. If it’s a Maven dependency, add an exclusion.

Spring Security 3 Setup

(Recovered from my old Blog).

Getting Spring Security setup only involves a few steps, but it can be confusing to work out exactly what they are – especially since almost all documentation refers to Spring Security 2, and there are a couple of differences.

The first thing to do is to add the Spring Security dependencies to your Maven pom.xml. A good explanation of which ones are needed is located here. In summary though, you probably want the following Artifact ids (Group id is org.springframework.security):

  • spring-security-core
  • spring-security-config
  • spring-security-web
  • spring-security-taglibs

(Note – be careful, for some reason the main Maven repository has a few spring-security-* artifacts under the Group id org.springframework – but they aren’t physically located there and you will get ‘Artifact Not Found’ errors).

After they are downloaded, you need to add the following to web.xml:

The extra context configuration puts all the security related information into a separate Spring xml for clarity (plus a different default namespace – we’ll see this in a minute).

The new filter does exactly as expected – intercepts calls to /* (sub-directories included) and applies the Spring Security rules (which we have yet to define).

As specified above, create the file /WEB-INF/applicationContext-security.xml. This file looks like a normal Spring config file, except instead of the default namespace being beans it is security – this means that all references to tags which are normally valid need to be prefixed with beans: (see below for an example).

Pay attention to this config – it is this file which is slightly different from Spring 2.

Breaking this file down, the ‘key’ tag is http. The auto-config attribute tells Spring Security to add in all the ‘normal’ configuration properties. As you get more comfortable with Spring Security, you may want to override some of these defaults (e.g. the form to show that captures login information).

The user-service tag adds a single valid user, ned. In a more likely scenario, the user-service will be hooked up to a database to get a list of valid users – that’s an exercise for another day.

The intercept-url patterns are fairly self-explanatory, with one caveat: Spring Security resolves them top-to-bottom, and chooses the first one that matches. Therefore, make sure your more granular, specific patterns are at the top and a catch-all like “/**” goes at the bottom.

Set the above into your Spring application, then try and access your_site/client/whatever.html. All being well, you should be prompted with the default Spring Security login page. Put in the credentials you entered into the user-service and you’re all set. Congratulations, you just secured your website using Spring Security!

SiteMesh with Spring MVC

(Recovered from my old Blog).

SiteMesh is an open source framework that implements the Decorator pattern. It essentially takes the output stream from a web application, and adds elements to (’decorates’) it. Why would we want that? Put simply, it is an incredibly clean way of adding headers/footers/anything, with the underlying jsp (or whatever) having no knowledge of that fact it will decorated. In combination with Spring MVC, this creates a powerful weapon for your developer arsenal.

This tutorial assumes you have an existing Spring MVC project.

To enable SiteMesh, first either include the jar in your lib folder or add it as a Maven dependency (opensymphony | sitemesh). Next, add the following to your web.xml:

Now we create a new file decorators.xml in WEB-INF. This file tells SiteMesh which files to map, and which ‘decorator’ (which we haven’t got to yet) to use. IMPORTANT – in most guides you see, it will tell you to map WEB-INF/jsp or similar. Remember, Spring MVC is handling the jsp references, so you actually want to point at your html folders/files (Spring MVC totally abstracts the jsp file layer).

The file master.jsp above is the decorator. Create a file called /WEB-INF/decorators/master.jsp containing the following:

And you’re done! Load any page in your Spring MVC application – and you should see the output has been decorated.

The two decorator tags above look at the pre-decorated page, pull out the respective head and body, and insert them into the output stream. For more complicated usage, see the SiteMesh homepage.

Now let’s look forward to SiteMesh 3!

Converting Spring MVC XML bean definitions into annotations

(Recovered from my old Blog).

As of Spring 2.5, annotations can be used on Spring MVC classes instead of defining each and every page in the *-servlet.xml definition file. However, most online guides still reference the old practice. Below is a simple guide to migrating to (in my opinion), the much cleaner annotation approach.

‘Normal’ Pages

Previously, ‘normal’ pages would:

  • Implement the Controller interface
  • Implement the handleRequest method
  • Have a simple *-servlet entry along the lines of:

Switching this to annotations is simple:

Firstly, add the context:component-scan element to your *-servlet.xml file, along with the Spring MVC annotation handlers:

For the above to work you will also need to add the context namespace URI to your main beans definition (third line down) and the schema to use (6th and 7th lines down):

Annotate your class with the @Controller annotation, and a @RequestMapping annotation which specifies which URL is mapped by this controller:

The method which handles the request (which – unlike the previous case where we implemented an interface – can have any name) should be annotated with @RequestMapping(method = RequestMethod.GET).

So the bean definition in *-servlet.xml is removed, and the class becomes:

Note that unlike the traditional xml based approach, the @RequestMapping annotation specifying which URL to map can be set at the method level (allowing multiple URLs to be mapped by a single Controller).

‘Form’ Pages

Form pages are a little more complicated. Previously, they would have:

  • Extending the superclass SimpleFormController
  • Overridden methods onSubmit and formBackingObject
  • Had a complicated bean definition containing all form options (e.g. which validator to use, which success page, etc)

To migrate these, first enable context:component-scan, along with the new Spring MVC annotation bean definitions as per the previous case.

Next, annotate the form class as per the ‘normal’ case. The method annotated with @RequestMapping(method = RequestMethod.GET) handles the initial ’setup’ of the form – basically what was previously handled in formBackingObject. This method also returns the view to use for the form. The command object will be initialised here, then stored in the model).

The method which is called when the ‘Submit’ button is pressed is annotated in a similar manner, except the RequestMethod is POST instead of GET. However, the differences then get larger:

There is no automated validation (assuming a validator is specified of course). See below how this is handled.
The validator will return a status. If there is an error we simply return the same view. If not, we set the SessionStatus to complete and return the name of the Success view to use.
To get at our command object we need to pull it out of the model – using the @ModelAttribute(“contactForm”) annotation.
As mentioned above, we need to call the validator directly. To do this, we need to @Autowire the validator into the class (as per normal Spring injection). Since we are no longer relying on Spring MVC calling the validator, we can improve the validate method on the validator to become typesafe, instead of passing in a generic object as before.

Complete class:

Breaking Up A Large Hibernate Class

(Recovered from my old Blog).

Over time, Hibernate classes can get very large – especially when modelling a complicated object (for example a financial transaction).

At this point, the @Embedded annotation comes to the rescue. The class annotated with @Embedded will be linked into the parent class as if it were one large class.

This even works with collections – the collection can be defined in the child (@Embeddable) class.

One caveat – we ought to be programming to interfaces rather than implementations. Assuming we marked an interface as @Embedded, Hibernate will scan the interface and not import any of the fields defined in the class. In this case, one simply adds the @Target annotation:

If using Criteria, this extra ‘level’ in the class hierarchy is simply referenced via a full-stop:

Simple Database Population Tool

(Recovered from my old Blog).

My source control contains many tables, many of which have dependencies on one another via foreign keys. When the table structures are being changed fairly regularly, it can be a pain to have to keep updating the database manually.

Ant has a built in SQL task which will pick up a file, then execute the contained statements on the database of your choice.

  1. Firstly, create the required scripts to be executed. For table creation scripts, I always add ‘DROP TABLE IF EXISTS’ (or a variant depending on SQL dialect) to make it easier to run a script on its own if it has no external dependencies.
  2. Create extra scripts for dropping the tables (with the commands in the correct order to respect foreign keys).
  3. Create an Ant build file (build.xml). Each script to be executed is placed in the file in order of execution (to again respect foreign keys).
  4. Execute Ant from the directory containing build.xml

Example for step one:

Example for step two (filename – drop_party.sql):

Example for step three (build.xml):

It is of course important that the JDBC driver referenced (in the example com.mysql.jdbc.Driver) is available to Ant. A simple way of doing this is to add the relevant jar to Ant’s lib directory.

MySQL Stored Procedures
The above technique works for MySQL stored procedures, with one minor change. When writing a MySQL stored procedure, the delimiter to use must be explicitly set (as ; is used within the stored procedures statements).

To set this delimiter, the ‘delimiter’ attribute within the sql tag must be provided.

For example:

Create an enum dynamically

(Recovered from my old Blog).

When creating an enum dynamically, there are two levels of difficulty.

The first case is where the type of the enum is known at compile-time, but the value is not. In this case, we can use the valueOf method of the enum in question:

The second, more complex case is where neither the type nor the value is known. The Enum base class (from whence all enums derive) contains a static method for this scenario:

This can result in Unchecked Invocation warnings so either proper checking will be required, or a suppression of the warning if absolutely sure.

In cases involving generics, it will be required to cast this call to prevent the “Bound mismatch” exception (essentially the compiler forcing the generic to be an implementation of Enum, which of course it must be since all enumerations derive from Enum).