Why is Spring bean lifecycle so elaborate?

[Trishul P Mukherjee]

Hi,

[Newbie question]

I was wondering why a Spring bean's lifecycle is so elaborate. According to the book Spring In Action - the life cycle consists of (just for reference) : Instantiate -> Populate properties -> BeanNameAware's setBeanName() -> BeanFactoryAware's setBeanFactory -> Pre-init BeanPostProcessors -> InitializingBean's afterPropertiesSet() -> Call custom init-method -> Post-init BeanPostProcessors (bean ready to use) ------- (container is shutdown) -> DisposableBean's destroy() -> Call custom destroy-method.

Reading about each stage in the book gives a fair idea of what it does, but I still don't "get" it - as in, I still don't get the "practicality" of these stages. Maybe some real world examples will help.

Thanks in advance.
Trishul.

[Mark Spritzler]

Good question. And in your post you actually are starting in the middle of the Initialization lifecycle. The whole life cycle is

1) Parse configuration
2) create BeanDefinition objects of each bean and put it into a Map
3) BeanFactoryPostProcessors which can modify the BeanDefinition objects

These steps help tell Spring all the beans it needs to create for you as well as the order to instantiate them.

Now to what you posted.

What do we need Spring to do for us, if the question I like to ask at this point. And answer it with

Well, we need it to instantiate our objects, do dependency injection, maybe call some init methods because we want to prepopulate our Cache for example.
Then we need Spring to add the Enterprise Abstractions like Transactions to our code. To add the abstractions Spring uses Spring AOP and creates Proxies around our real objects.

So to do that. Spring goes one by one for each bean it needs to create.

It first instantiates the bean and sets its dependencies and properties that were configured.

Then there are a few Aware interfaces that your classes can implement (I don't recommend doing this as it couples your code to Spring)
But these aware interfaces are just so the instance of the bean can know when id you gave it or to hold a reference to the ApplicationContext it is in, in case you ever have to call getBean in that bean.

After that the instance is passed to a collection of BeanPostProcessors that can act on the newly instantiated beans. It can call an init method for you, but more importantly, it can create a Proxy of you bean for you and add all the enterprise abstractions.

All this "Pre-init BeanPostProcessors -> InitializingBean's afterPropertiesSet() -> Call custom init-method -> Post-init BeanPostProcessors" is basically the BeanPostProcessor step.

After all the beans have gone through this, they are now all ready to use.

Hope that helps clear things up for you

Mark

[Trishul P Mukherjee]

Thanks Mark - appreciate the quick reply. That does help

I got most of what you said except ".....After that the instance is passed to a collection of BeanPostProcessors that can act on the newly instantiated beans. It can call an init method for you, but more importantly, it can create a Proxy of you bean for you and add all the enterprise abstractions."

Could you explain that a little more? Probably am asking this 'cause I don't understand the concept of Spring proxies or their utility in general.

Thanks.
Trishul

[Mark Spritzler]

Trishul P Mukherjee wrote:Thanks Mark - appreciate the quick reply. That does help

I got most of what you said except ".....After that the instance is passed to a collection of BeanPostProcessors that can act on the newly instantiated beans. It can call an init method for you, but more importantly, it can create a Proxy of you bean for you and add all the enterprise abstractions."

Could you explain that a little more? Probably am asking this 'cause I don't understand the concept of Spring proxies or their utility in general.

Thanks.
Trishul

Sure.

In most applications you need functionality like Transactions, Data Access, maybe Security, and other features. If you put that code directly in your classes then you start to couple your code to those features and you lose cohesion in your methods and classes. When you then get to testing that code you have to not only test your code, but also those features in combintation. When the code is in your classes you now have the same code scattered throughout your code and coupled or tangled with those functionality.

If I want to write a method to say transfer money between accounts, I want that transfer method to do just that and only that. Not also security and transactions and logging etc. So it would be nice to have that functionality added without writing that code directly in the classes.

That is where AOP/proxies come in. We can now wrap your code in a proxy and add to that proxy the extra needed functionality. The proxy will have a reference to your real object as well as the objects that do transaction, security etc, and the client will just be calling into the proxy instead of directly to your class, and therefore now you have a transfer that has transactions around it and is secure. You code stays clean and very easy to test.

Hope that helps

Mark

[Trishul P Mukherjee]

Thanks again !

[Jayesh A Lalwani]

Trishul, That is a very good question