BeanPostProcessor vs BeanFactoryPostProcessor

BeanFactoryPostProcessors affect BeanDefinition objects because they are run right after your configuration is read in. There are no bean instances created yet. So it can’t do anything to your objects instances yet. For Example the PropertyPlaceholderConfigurer is a BeanFactoryPostProcessor, which looks through the BeanDefinition objects and replaces any ${property.name} with the actual value of property.name from a Properties file, or System.getProperty() or environment variables.

BeanPostProcessors affect instances of your objects. For example here is where Spring AOP decides to create proxies for your beans.

So you declare transactions or AOP Aspect JoinPoints to run code when certain methods are called on your beans.

Well how is Spring going to add that “Code” to your code. It uses proxies. So when you call your business logic method, you want it to start a transaction. So in the BeanPostProcessing phase, Spring will see that you defined transactions on that method, it will create a Proxy object and wrap it around your actual bean instance, and it will put the Proxy object into the ApplicationContext/BeanFactory’s HashMap under the beans name.

So now when you call getBean() what you get back isn’t the actual Bean Instance, but the Proxy instead that holds the actual bean Instance.

Without the BeanPostProcessor phase, Spring would not be able to do that.

some example

some video series 14-16

Advertisements

One comment

  1. Pingback: spring IoC life cycle | Life in USA

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