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).

Sharing Resources between Maven modules

(Recovered from my old Blog).

I needed to share resources between modules in a multi-module Maven project. The resources in question are configuration data files which are converted into objects via XStream (plus some Spring Bean configuration files). The reason they need to be shared is for instantiation within module-specific JUnit tests.

After some thinking and Googling around, I think I have come up with the ‘cleanest’ structure. My first thought was to put them into the parent module, but after messing around with configuration, I began to realise this was a bad idea.

My new solutions goes like this:

  • Create a new sub-module (called config or whatever)
  • Put a dependency to this new module in the pom.xml for all other modules
  • Even though these are test resources, put them in /src/main/resources so they are packaged into the jar (or obviously change the default packaging so it includes the /src/test/resources)

Quite clean I think.

Injecting Resources into Spring Beans

(Recovered from my old Blog).

This is mentioned in passing in the Spring documentation – but to highlight:

Spring will automatically convert a String in a bean definition into a Resource if required.

If the target Resource is a specific class (e.g. UrlResource) then the passed in string must match the format, or a runtime error will ensue.

For example:

view source

Persisting a Collection with an arbitrary enum type

(Recovered from my old Blog).

As we know, enums are great for storing (relatively) static domain information.

But let’s say we want an object which models (and can persist) a collection of elements where we are not sure at design time which domain information will be stored. For example, a set of attributes describing a financial trade – TransactionSource, BusinessFlow, TradingStrategy, etc. While we could model these all separately, it would be nice to have a single collection of attributes.

In this scenario, we could create a collection (and associated methods) which manipulate Object, but in today’s typesafe world there has to be something better.

I propose creating an empty interface, then having all enums implement it:

Then, the consuming code becomes simple:

Note that Hibernate will confused when trying to persist TransactionAttribute (as it won’t be able to determine the type of TransactionAttributeInterface). This could be solved by creating a new Hibernate UserType (see https://www.hibernate.org/272.html), or more easily by mapping to a String internally for persistence: