h1

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.

Advertisements

2 comments

  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 )

Twitter picture

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

Facebook photo

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

Google+ photo

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

Connecting to %s

%d bloggers like this: