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:

Fun With Hibernate Inheritance

(Recovered from my old Blog).

I had a relatively simple requirement, with a relatively simple solution – but it is worth recording for simple reference.

Suppose I have two Hibernate classes Cat and Dog, both of which derive from the abstract class Animal. Suppose further that both Cats and Dogs can have a child collection of the class Toy.

Since Set<Toy> is shared, we want to do all the hard work in the Animal class, rather than repeat it twice.

Finally, assume that for convenience sake – the underlying table structure is shared, with just a column to indicate whether the entry is a CAT or a DOG.

All very simple so far.

If we want to annotate this class to fulfill the requirements above, we have to:

Declare Cat and Dog as @Entity, since these become the instantiated classes.
Important – Animal also needs to be an @Entity to allow for the @ManyToOne mapping in Toy. (Remember – we said we wanted the ToySet to be shared. If you don’t declare Animal as an @Entity we will get ‘unknown entity’ exceptions.
State that Animal is the top of tree with @Inheritance.
Tell Hibernate which column should be used to discriminate between classes when mapping with @DiscriminatorColumn.
So our classes become:

Django Homepage With Multiple Apps

After completing the Django tutorial, I was a little confused as to how one is supposed to structure the homepage for a web application containing multiple applications.

There seem to be three common approaches:

  • Flatpages – https://docs.djangoproject.com/en/dev/ref/contrib/flatpages/
  • Create a separate dedicated app
  • Create a new views.py in the “project” folder which contains your settings.py

Flatpages are static content pages which are saved in the database backing your Django application.  This makes creating a homepage very easy, but also – by definition – static.  This is probably most useful for things like an “About Us” page.  A homepage will surely have dynamic content (e.g. latest news).

I opted to create a views.py in my project folder for now.  If this doesn’t work, I will look at creating a “general” application that fills the gaps between the specific dedicated apps.