Bean Creation via Factory Method

The Spring Container does not have to instantiate beans via using the new keyword. Some times objects are created from factories. There are two ways to achieve the same - via a static factory method or via an instance factory method.

Using BeanPostProcessors

Spring provides us with BeanPostProcessor classes that can be used to process beans before and after they have been configured by the container.

Creating default init and destroy methods

In earlier post we saw how Spring allowed us to define custom init and destroy methods - both via configuration and via code.As we are working with cars, we will need to check the engine on all cars before use and clean the car after use.

The InitializingBean and DisposableBean Interfaces

In our previous post we saw how the Spring container used custom initialization and destroy methods. An alternative way to achieve the same is to use the InitializingBean and DisposableBean Interfaces.

Custom Bean Initialization and Destroy Methods

It is possible that we may need to execute some initialization code when the bean has been initialized successfully by the Spring Container. We saw that the bean life cycle has several methods that can be used to initialize our bean.

BeanNameAware and BeanFactoryAware

In the previous post we saw the Bean life cycle. Consider the two interfaces BeanNameAware and BeanFactoryAware. The first one makes the object aware of their bean name in a bean factory. The second interface gives the bean access to the Bean Factory that created it.

The Bean Lifecycle

I was studying the life cycle of the bean in a Spring application. The Spring container performs several step in the bean creation process before making it available to the use for the application.

The autowire-candidate attribue

There may arise a scenario wherein we do not want certain beans to be autowired into the property of other beans. Consider the Simple Car class from an earlier example:

The default-autowire attribute

We have seen that Spring supports a variety of auto-wiring options. Spring Container allows us to set a default autowiring for all the beans.

Can we auto and explicitly wire a bean ?

While the Spring Container allows us to auto-wire a bean, it does not mean, that the bean must be completely auto wired by the container.

Autodetecting The Autowiring

The last technique in autowiring is auto-detect. In this case we tell the Spring container to uses its own brains while configuring the bean.

One to One and Proxies

As a part of its default fetch strategy, Hibernate uses proxies for collections and all associations when we get an Entity from the database. The proxies have only their id set with access to any other property triggering a further select statement. The idea here is to only hit these tables when the data is needed. But the behavior varies slightly for one to one associations.

Lazy Behavior in Hibernate

Hibernate has an attribute called lazy. This makes an appearance in various parts of the hbm file. The first point is the class element. (To try these properties, I am using the same Book- Shelf example from an earlier post.)

hibernate.use_identifier_rollback

Consider the below code that loads an entity from the database and deletes it.

public static void rollBackDelete() {
    Session session = sessionFactory.openSession();
    Entity entity = new Entity();