jump to navigation

Spring Aggregating MessageSource March 26, 2010

Posted by Phill in General J2EE, Spring.
Tags: , , ,
comments closed

If you’ve ever worked on a modular project which needs to be internationalised, chances are you’ll have run into the requirement of combining messages from various different modules.

By that I mean, each module has its own message source, but you want them to be combined into one MessageSource. This could be required for various different reasons which I won’t go into here, but suffice it to say that this is possible with Spring.

I created an AggregatingMessageSource which would scan the ApplicationContext for instances of MessageSource. When a message was requested, it would search each one sequentially for the relevant message.

Anyway, if you need such a class, I have uploaded it to get you started. Obviously, customise it to your own needs: AggregatingMessageSource.java.


Fun with Spring, GWT and Annotations March 4, 2010

Posted by Phill in Frameworks, Spring.
Tags: , , , ,
comments closed

Recently I’ve been porting across some of our monolithic IceFaces application to a more modular GWT application. (There’s nothing wrong with IceFaces as such, but for several reasons I don’t think it’s the right fit for us any more).

It’s been going pretty well so far, although I’ve only been working on it for a few days. I’ve got the GWT-Widget server library up and running as well, which integrates nicely with Spring for RPC. (It basically means you don’t have to define a new servlet in web.xml for each RPC server you want, you can just define them as Spring beans).

However, it does mean that you have to create a mapping for each Spring bean that you want to publish and define it in the application context XML, which isn’t really ideal for modular applications: I’d quite like them to be detected automatically with annotations, that way if you have another module on the classpath it will automatically be picked up.

So, I created another annotation (@RPCService) and annotated my RPC endpoints with it. The annotation, as its value, had the URL of that endpoint (i.e. “/user” for the users RPC service)

Then, my initial thought was to use Spring to scan the classpath and load each one up. I’ll cut a long story short here and say that was all unecessary: if your RPC classes are defined in the application context (via XML or annotations, it doesn’t matter), all you need to do is get an instance of the Application Context and call getBeansWithAnnotation.

This makes things really simple: I have a bean set up which has an initialise method that uses that method to get all classes annotated with my RPCService annotation, finds out their URLs, and then configures the GWTHandler servlet to map those beans.

Dead easy! And very useful to do, if you’re using the GWT-Widgets library.

Edit: After reading the documentation it seems that what I’ve done is essentially re-implement what’s already available in the library. Still, hopefully it will come in useful if you need to do something similar for another usage…

JUnit, Spring, and database transactions March 9, 2009

Posted by Phill in Testing.
Tags: , , , ,
comments closed

Quick post: I have a suite of tests running against the database. All of these tests need to run in a transaction – which is then rolled back at the end.

However, due to unusual circumstances I needed one specific test to run without a transaction. It turned out this is fairly easy to do in Spring, using AbstractTransactionalDataSourceSpringContextTests (a class Spring provides for running tests in transactions). You just need to override the runBare method:

public void runBare() throws Throwable
  if (getName().equals( "methodName" ))


Easy when you know how! There was nothing in the docs detailing this code exactly, but I managed to figure it out with a combination of javadocs and reading the source code (probably unnecessary, but still).

Spring and PropertyPlaceholderConfigurers October 22, 2008

Posted by Phill in Spring.
Tags: , , , ,
comments closed

The project I’m currently working on is a fairly modular web app. We have an application context file for each module. This has worked pretty well so far. However, I ran into an issue today when I wanted to add a new module: I kept getting the issue ‘Could not resolve placeholder ‘(property name)’.

I thought this was a bit strange because I thought I’d set up the property configurer correctly, and the properties file was definitely in the right place.

It turns out (via a bit of Googling – see this thread) that you don’t need multiple PropertyPlaceholderConfigurers. If one is defined, it will load properties for the whole of your application context files (as long as they’re within the same overall context).

If you have multiple PropertyPlaceholderConfigurers defined, what will happen is that if one of them can’t find a specific property, it will treat it as a fatal exception. This is of course going to happen if your different configurers point to different properties files!

There are three solutions:

  • Set the “ignoreUnresolvablePlaceholders” attribute on all property placeholder;
  • Set the “placeholderPrefix” or “placeholderSuffix” properties individually for each one so they don’t all match ${…}
  • Use one property placeholder configurer and just point it to all your properties files.

I’ve gone with the last option at the moment – it’s the best solution for what we need at the moment.

Spring Transactions across multiple datasources September 16, 2008

Posted by Phill in Other Stuff, Spring.
Tags: , , , ,
comments closed

Update: Since writing this post I have discovered problems with the Enhydra connection pool, and as such I do not recommend using it. I recommend finding another way to accomplish what you want to do.

We have an application here which connects to two different data sources. I was having problems getting the application to be transactional using Springs @Transactional annotation. The problem is, the Transactional annotation does not let you specify a transaction manager – and one transaction manager can only manage one DataSource. Or so I thought.

It turns out that it is possible, using JTA – and JOTM.

The configuration you need is pretty minimal. In your application context XML file, you need to put the following:

<bean id="jotm"
class="org.springframework.transaction.jta.JotmFactoryBean" />

<bean id="innerDataSource"
<property name="transactionManager" ref="jotm" />
<property name="driverName" value="${dataSource.driver}" />
<property name="url" value="${dataSource.url}" />
<property name="user" value="${dataSource.username}" />
<property name="password" value="${dataSource.password}" />

<bean id="dataSource"
<property name="dataSource" ref="innerDataSource" />
<property name="user" value="${dataSource.username}" />
<property name="password" value="${dataSource.password}" />

<bean id="transactionManager"
<property name="userTransaction" ref="jotm" />

(You also need to set up your libraries to inculde JOTM and the XA Data Sources – which can be got here)

This is for the first DataSource. Your second DataSource should be set up as per the above, except that you don’t need to repeat the jotm or transactionManager beans.

Provided that you then set up your transactions as annotation-driven – and actually use a few annotations – you should find your methods are transactional across multiple dataSources!

You may also find it helps to read a couple of articles on the subject, two which I found helpful are here and here.

Feeling like an idiot September 3, 2008

Posted by Phill in Spring, Testing.
Tags: , , ,
comments closed

Do you ever spend a whole morning tracking down a problem, only to find out that it was your own stupid fault in the first place? I do. I did this morning.

I wrote a unit test a while back which tries to insert some data into a database (in a transaction), and then the transaction should be rolled back. (The transactions are handled automagically by AbstractTransactionalSpringContextTests). It all seemed to be working fine – the data was being inserted OK and then rolled back.

However, this morning I noticed that the data was not being rolled back. “That’s strange”, I thought, “I’m sure it was working a few weeks ago…”. I tried turning on debug logging. Spring made absolutely no mention of transactions for those particular tests.

I tried a number of things, including messing around with my Spring configuration – nothing!

Long story short, it turns out that the problem was incredibly simple:

In my unit test class, I’d overridden onSetUp, but hadn’t called super.onSetUp(). The AbstractTransactionalSpringContextTests class makes use on onSetUp to start the transaction. Doh! So, a quick call to super.onSetUp() at the start of my onSetUp method and everything seems to be working again…

This just demonstrates, though – always be sure what you’re overriding before you override it!

More on JSF and Spring Integration: MessageSources June 18, 2008

Posted by Phill in Frameworks.
Tags: , , ,
comments closed

A couple of days ago I wanted to move my application messages file out of the classpath into WEB-INF for some reason which I can’t actually remember now. Anyway, Spring definitely supports loading message files from WEB-INF, but I don’t think JSF does (I think it loads resources from the classpath).

Plus, it makes sense to have all messages loaded from the one MessageSource – that way, if I add another messages file, the configuration will only need to be changed in one place.

After a bit of Googling, I managed to get it to work. If you want to have JSF using a Spring MessageSource, you will need to use the following class: MessageSourcePropertyResolver. Copy and paste that into your codebase somewhere. Then, edit your faces-config.xml file and add in the appropriate element:


Then, you can use the MessageSource in your JSF pages like this:#{messageSourceBeanName[‘message.key’]}

Tip: I don’t like typing out “messageSource” every time I want to use a message in a JSF page – I always used the shorter “msg” before. You can do this with Spring – just alias your MessageSource bean with the name “msg”. For example,

<alias name=”messageSource” alias=”msg” />

JSF Backing Beans and Spring May 2, 2008

Posted by Phill in General J2EE.
Tags: , ,
comments closed

In the Spring Documentation about JSF integration, the DelegatingVariableResolver (and a few alternatives) are explained. There is one thing it doesn’t mention explicitly, though, which is using Spring managed beans as backing beans.

As it happens, it’s fairly easy: you just need to use beans with request or session scope. There is a little bit of configuration needed for this, but you get the great benefits of having all your bean definitions in one place, as well as all the benefits of Spring managed beans and configuration!

Provided that you have the DelegatingVariableResolver (or one of the equivalents) set up, you can then use
your Spring managed beans in exactly the same way as you would use JSF managed beans.

Spring’s Log4JWebConfigurer October 12, 2007

Posted by Phill in Spring.
Tags: , ,
comments closed

In the JavaDoc for Spring’s Log4JWebConfigurer, there’s a bold “warning”, letting you know that it “Assumes an expanded WAR file”. If you want to use an unexpanded WAR file, the advice is to use a VM-wide Log4J setup.

Unfortunately, in our case we needed to have our application use a particular Log4J properties file, and we needed it to be outside the WAR file (i.e. in a shared properties folder on the server). The shared properties folder is on the classpath – so it is available to the application – but unfortunately our EAR file is unexpanded.

In the end, we managed to get it to work: in web.xml, you can add a “classpath:” attribue to the log4jConfigLocation attribute. You also need to set the log4jExposeWebAppRoot property, otherwise (on WebLogic at least) the deployment will fail with an error about setting the WebApp home for an unexpanded EAR file.

Reloadable properties in Spring July 31, 2007

Posted by Phill in Spring.
Tags: , ,
comments closed

One of the issues I faced last week was to do with properties, specifically property reloading: in Spring, if you use something like PropertyPlaceholderConfigurer, the properties get set when the ApplicationContext loads up but then nothing happens when the properties change (even if you use the reloadable resource bundle).

This is only really a problem if you want to (for example) change a timeout value in the properties file. You can change it all you want, but if that value was dependency-injected via the PropertyPlaceholderConfigurer than you’re out of luck!

I was going to try and come up with a solution for this, but fortunately it seems that someone already has. I haven’t tested it yet, but it looks like it will do the job rather nicely.