Post Processors in Spring’s Autowired world

November 9, 2008

I have been a huge fan of the Spring Framework ever since I came across it. I have trouble remembering how I overcame all the obstacles of dependency injection (not to mention thread pooling, jdbc access etc) in the pre-Spring era. While building Aloha, I had gotten quite used to the idea of post-processors (in addition to the init-method and destroy-method attributes on each bean), enabling me to write setup code for my application once all the beans had been instantiated and initialised.

Now, as part of the Ribbit team, I am working for the first time with Spring 2.5, with beans being autowired using annotations*. A few days ago, I wrote my first post-processor for the application. Unit tests passed with no issues, but when Uros tested the post-processor against our test environment, it turned out the post-processor executed BEFORE all the beans had finished their initialization. This was, without a doubt, a shock to the system. He got around the problem by implementing the same solution on receiving a Spring ContextRefreshedEvent.

Though this solved the problem, I was stumped by the fact that a post-processor no longer behaved like its very name suggested. The only explanation I could think of was that the post-processor executed after the beans in applicationContext.xml were initialized, but before the initialization of the autowired ones. A quick search gave me the “autowired” way of post processing: the @PostConstruct and @PreDestroy annotations**. I just tried them out locally and they work without a hitch. However, since we already have a working solution, I won’t be checking this in, but will definitely keep it in mind for the next time!

* I am yet to make up my mind on whether I am for autowiring or not – the obvious benefit is that everytime you add a dependency to a bean, you are not required to go edit an xml file somewhere to wire everything together. On the flip side, it is sometimes convenient to go look up a listing of all beans and their dependencies in one place!

** These annotations are part of Java 6, but since we still use Java 5 in our project, we need to include common-annotations.jar, available as part of the Spring download, in our lib directory.



  1. Hey! Don’t stop there! Make it work…done.

    Make it right!

    Since when do we stop at make it work?

  2. Good point! Two things really – one that the current solution isn’t necessarily wrong – it’s just that it is more code and possibly less elegant. The second is that by the time I tried out the solution locally and ensured it worked, we were very close to code freezing for the current release and I didn’t think it was appropriate to check in a shallow change like this.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: