What features are provided by Spring Bean definition ?

ID / name of bean (id attribute)

Bean IDs must be unique within the container the bean is hosted in.

<bean id="exampleBean" class="examples.ExampleBean"/>

In a bean definition itself, you may supply more than one name for the bean, by using a combination of up to one name specified via the id attribute, and any number of other names via the name attribute. All these names can be considered equivalent aliases to the same bean.

It is sometimes desirable to introduce an alias for a bean which is defined elsewhere.

<alias name="fromName" alias="toName"/>

A bean in the same container which is named 'fromName', may also be referred to as 'toName' (after the use of this alias definition)

Instantiation of bean (class attribute)

Instantiation using a constructor

<bean id="exampleBean" class="examples.ExampleBean" />

Instantiation using a static factory method

Defining a bean which is to be created using a static factory method, along with the class attribute which specifies the class containing the static factory method, another attribute named factory-method is needed to specify the name of the factory method itself.

<bean id="exampleBean" class="examples.ExampleBean2"  

      factory-method="createInstance" />

Instantiation using an instance factory method

<!-- Factory bean, which contains a method called createInstance() -->

<bean id="serviceLocator" class = "com.foo.DefaultServiceLocator">

  ......

</bean>

<!-- the bean to be created via the factory bean -->

<bean id="exampleBean" factory-bean="serviceLocator" 

      factory-method="createInstance" />

Scope of bean (scope attribute)

Spring 2 provides only singleton and prototype scopes but Spring 2.5 provides additional scopes also.

1. singleton : Scopes a single bean definition to a single object instance per Spring IoC container.

2. prototype : Scopes a single bean definition to any number of object instances.

3. request : Scopes a single bean definition to the lifecycle of a single HTTP request; that is each and every HTTP request will have its own instance of a bean created off the back of a single bean definition. Only valid in the context of a web-aware Spring ApplicationContext.

4. session : Scopes a single bean definition to the lifecycle of a HTTP Session. Only valid in the context of a web-aware Spring ApplicationContext.

5. global session : Scopes a single bean definition to the lifecycle of a global HTTP Session. Typically only valid when used in a portlet context. Only valid in the context of a web-aware Spring ApplicationContext.

Constructor arguments (constructor-arg tag)

Argument Type Matching

<bean id="exampleBean" class="examples.ExampleBean">

   <constructor-arg type="int" value="7500000" />

   <constructor-arg type="java.lang.String" value="42" />

</bean>

Argument Index

<bean id="exampleBean" class="examples.ExampleBean">

   <constructor-arg index="0" value="7500000"/>

   <constructor-arg index="1" value="42"/>

</bean>

Setter Injection by Property definition (property tag)

<bean id="exampleBean" class="examples.ExampleBean">

   <!-- setter injection using the nested <ref /> element -->

   <property name="beanOne">

       <ref bean="anotherExampleBean" />

   </property>

   <!-- setter injection using the neater 'ref' attribute -->

   <property name="beanTwo" ref="yetAnotherBean" />

   <property name="integerProperty" value="1" />

</bean>

<bean id="anotherExampleBean" class="examples.AnotherBean" />

<bean id="yetAnotherBean" class="examples.YetAnotherBean" />

Autowiring mode (autowire attribute)

Autowiring is specified per bean and can thus be enabled for some beans, while other beans will not be autowired. Using autowiring, it is possible to reduce or eliminate the need to specify properties or constructor arguments, thus saving a significant amount of typing.

no : No autowiring at all.

Bean references must be defined via a ref element.

This is the default, and changing this is discouraged for larger deployments, since explicitly specifying collaborators gives greater control and clarity.

byName : Autowiring by property name.

This option will inspect the container and look for a bean named exactly the same as the property which needs to be autowired.

For example, if you have a bean definition which is set to autowire by name, and it contains a master property (that is, it has a setMaster(..) method), Spring will look for a bean definition named master, and use it to set the property.

byType : Allows a property to be autowired if there is exactly one bean of the property type in the container.

If there is more than one, a fatal exception is thrown, and this indicates that you may not use byType autowiring for that bean.

If there are no matching beans, nothing happens; the property is not set. If this is not desirable, setting the dependency-check="objects" attribute value specifies that an error should be thrown in this case.

constructor : This is analogous to byType, but applies to constructor arguments.

If there isn't exactly one bean of the constructor argument type in the container, a fatal error is raised.

autodetect : Chooses constructor or byType through introspection of the bean class.

If a default constructor is found, the byType mode will be applied.

Checking dependencies (dependency-check attribute)

It is useful when you want to ensure that all properties (or all properties of a certain type) are set on a bean.

Dependency checking can also be enabled and disabled per bean, just as with the autowiring functionality.

The default is to not check dependencies (none).

none : No dependency checking. Properties of the bean which have no value specified for them are simply not set.

simple : Dependency checking is performed for primitive types and collections (everything except collaborators)

object : Dependency checking is performed for collaborators only.

all : Dependency checking is done for collaborators, primitive types and collections.

Lazy-instantiation (lazy-init attribute)

The default behavior for ApplicationContext implementations is to eagerly pre-instantiate all singleton beans at startup. Pre-instantiation means that an ApplicationContext will eagerly create and configure all of its singleton beans as part of its initialization process.

If you do not want a singleton bean to be pre-instantiated when using an ApplicationContext, you can selectively control this by marking a bean definition as lazy-initialized.

A lazily-initialized bean indicates to the IoC container whether or not a bean instance should be created at startup or when it is first requested.

<bean id="lazy" class="com.foo.ExpensiveToCreateBean"

      lazy-init="true"/>

It is also possible to control lazy-initialization at the container level by using the 'default-lazy-init' attribute on the <beans/> element.

<beans default-lazy-init="true">

   <!-- no beans will be pre-instantiated... -->

</beans>

Initialization callbacks (init-method attribute)

Bean definitions provide support for a generic initialization method to be specified.

<bean id="exampleInitBean" class="examples.ExampleBean"

      init-method="init" />

Destruction callbacks (destroy-method attribute)

Bean definitions provide support for a generic destroy method to be specified.

<bean id="exampleInitBean" class="examples.ExampleBean"  

      destroy-method="cleanup" />