Spring Framework - XML configuration file - Part I

In this post the Spring framework's XML configuration file is presented. This files are the heart of Spring framework. Understand using these files is very important to understand Spring framework itself.


Part I - This part of post is about the XML scheme, the root element, the tags inside the root element and the properties of the <bean/> tag.

XML Scheme
To use the XML file with Spring framework, we have to start our XML file like this:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN"
"http://www.springframework.org/dtd/spring-beans.dtd">

These lines mean our XML file version is 1.0 and the encoding of the file is UTF-8. It's recommended keep these settings.

The next two lines is a DTD import. It can be used to check the validation of our XML file.

Root element
All XML file have to be a root element. If we create XML configuration file to Spring framework then the root element must be:

<beans>
...
</beans>

All bean definition, configuration code and everything have to be between the beans open and close tag.

The following tags are allowed inside the <beans/> element:

• alias,
• bean,
• description,
• import.

<import/> tag: Importing beans from other XML files
It can be very useful when we can separate the beans to several XML files based on the business logic. Other benefit is the support of the team work. Everybody can work with its own beans and program code and using import tag, the XML files can be logically merged.

Importing beans from other XML file:

<import resource="an_other_xml_file.xml" />

<alias/> tag: Aliasing beans
Using <alias/> tag we can give alias names to beans. This means we can give new reference-name to the bean:

<alias name="the_exist_name_of_bean" alias="the_new_name_of_bean" />

<description/> tag: Writing descriptions, comments
Using <description/> tag we can write descriptions, comments to our XML configuration file:

...
<description>
Some important description...
<description/>
...

<bean/> tag: Defining beans
A Spring IoC container manages one or more beans. These beans are created using the configuration metadata that has been supplied to the container
.
Within the container itself, these bean definitions are represented as BeanDefinition objects, which contain (among other information) the following metadata:

• a package-qualified class name: typically this is the actual implementation class of the bean being defined,
• bean behavioral configuration elements, which state how the bean should behave in the container (scope, lifecycle callbacks, and so forth),
• references to other beans which are needed for the bean to do its work; these references are also called collaborators or dependencies,
• other configuration settings to set in the newly created object. An example would be the number of connections to use in a bean that manages a connection pool, or the size limit of the pool.

The <bean/> tag has the following attributes:

• abstract
• autowire
• class
• dependency-check
• depends-on
• destroy-method
• factory-bean
• factory-method
• id
• init-method
• lazy-init
• name
• parent
• singleton

<bean/> tag, abstract property
We can mark a bean explicit abstract. In this case we can define bean template without specifying its class. This abstract beans can use as parent of well-defined beans.

Example:

<bean id="beanId" class="pack.example.MyClass" abstract="true">
<property name="myProp" value="sample"/>
<bean/>

<bean/> tag, autowire attribute
The Spring container is able to autowire relationships between collaborating beans. This means that it is possible to automatically let Spring resolve collaborators (other beans) for your bean by inspecting the contents of the BeanFactory. The autowiring functionality has five modes. 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. When using XML-based configuration metadata, the autowire mode for a bean definition is specified
by using the autowire attribute of the <bean/> element. The following values are allowed:

• 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. To some extent, it is a form of documentation about the structure of a system.
• 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.

Example:

<bean id="beanId" class="pack.example.MyClass" autowire="no"/>

<bean/> tag, class attribute
Using class property we can specify the class of the bean. The class definition must be contain the package name and the class name
Example:

<bean id="beanId" class="pack.example.MyClass"/>

<bean/> tag, dependency-check attribute
The Spring IoC container also has the ability to check for the existence of unresolved dependencies of a bean deployed into the container. These are JavaBeans properties of the bean, which do not have actual values set for them in the bean definition, or alternately provided automatically by the autowiring feature. This feature is sometimes useful when you want to ensure that all properties (or all properties of a certain type) are set on a bean. Of course, in many cases a bean class will have default values for many properties, or some properties do not apply to all usage scenarios, so this feature is of limited use. Dependency checking can also be enabled and disabled per bean, just as with the autowiring functionality. The default is to not check dependencies. Dependency checking can be handled in several different modes. When using XML-based configuration metadata, this is specified via the 'dependency-check' attribute in a bean definition, which may have the following values:

• 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.

Example:

<bean id="beanId" class="pack.example.MyClass" dependency-check="none"/>

<bean/> tag, depends-on attribute
For most situations, the fact that a bean is a dependency of another is expressed by the fact that one bean is set as a property of another.

For the relatively infrequent situations where dependencies between beans are less direct (for
example, when a static initializer in a class needs to be triggered, such as database driver registration), the 'depends-on' attribute may be used to explicitly force one or more beans to be initialized before the bean using this element is initialized. Find below an example of using the 'depends-on' attribute to express a dependency on a single bean:

<bean id="myClass" class="pack.example.MyClass"/>
<bean id="myOtherClass" class="pack.example.MyOtherClass"/>
<bean id="beanId" class="pack.example.MyImportantClass" depends-on="myClass,myOtherClass"/>

<bean/> tag, destroy-method attribute
Implementing the org.springframework.beans.factory.DisposableBean interface allows a bean to get a callback when the container containing it is destroyed. The DisposableBean interface specifies a single method:

void destroy() throws Exception;

Other way to define destruction callback is the destroy-method attribute. We can set a method of the class, that is invoced before it is destroyed:

<bean id="myClass" class="pack.example.MyClass" destroy-method="cleanup"/>

In this case the cleanup() method is invoced before the bean is destroyed.

<bean/> tag, factory-bean, factory-method attributes
We can use factory method instead of constructor. We have two options to do that:

• static factory method
• instance factory method

Static factory method
When 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. Spring expects to be able to call this method (with an optional list of arguments as described later) and get back a live object, which from that point on is treated as if it had been created normally via a constructor. One use for such a bean definition is to call static factories in legacy code.

The following example shows a bean definition which specifies that the bean is to be created by calling a factory-method. Note that the definition does not specify the type (class) of the returned object, only the class containing the factory method. In this example, the createInstance() method must be a static method:

<bean id="exampleBean" class="examples.FactoryBean" factory-method="createInstance"/>

Instance factory method
Instantiation using an instance factory method is where a non-static method of an existing bean from the container is invoked to create a new bean. To use this mechanism, the 'class' attribute must be left empty, and the 'factory-bean' attribute must specify the name of a bean in the current (or parent/ancestor) container that contains the instance method that is to be invoked to
create the object. The name of the factory method itself must be set using the 'factory-method' attribute. The createInstance method is an instance method of examples.FactoryBean class here:

<bean id="factoryBean" class="examples.FactoryBean"/>
<bean id="exampleBean" factory-bean="factoryBean" factory-method="createInstance"/>

<bean/> tag, id, name attributes
Every bean has one or more ids (also called identifiers, or names; these terms refer to the same thing). These ids must be unique within the container the bean is hosted in. A bean will almost always have only one id, but if a bean has more than one id, the extra ones can essentially be considered aliases.

When using XML-based configuration metadata, you use the 'id' or 'name' attributes to specify the bean identifier(s). The 'id' attribute allows you to specify exactly one id, and as it is a real XML element ID attribute, the XML parser is able to do some extra validation when other elements reference the id; as such, it is the preferred way to specify a bean id. However, the XML specification does limit the characters which are legal in XML IDs. This is usually not a constraint, but if you have a need to use one of these special XML characters, or want to introduce other aliases to the bean, you may also or instead specify one or more bean ids,
separated by a comma (,), semicolon (;), or whitespace in the 'name' attribute.
Please note that you are not required to supply a name for a bean. If no name is supplied explicitly, the container will generate a unique name for that bean.

Example:

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

<bean/> tag, init-method attribute
Implementing the org.springframework.beans.factory.InitializingBean interface allows a bean to perform initialization work after all necessary properties on the bean have been set by the container. The InitializingBean interface specifies exactly one method:

void afterPropertiesSet() throws Exception;

Other way to define initialization callback is the init-method attribute. We can set a method of the class, that is invoced after all necessary properties on the bean have been set.

<bean id="myClass" class="pack.example.MyClass" init-method="initBean"/>

In this case the initBean() method is invoced after all necessary properties on the bean have been set.

<bean/> tag, 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. Generally this is a good thing, because it means that any errors in the configuration or in the surrounding environment will be discovered immediately.

However, there are times when this behavior is not what is wanted. If we 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 equested.

When configuring beans via XML, this lazy loading is controlled by the 'lazy-init' attribute on the <bean/> element; for example:

<bean id="myClass" class="pack.example.MyClass" lazy-init="true"/>

<bean/> tag, parent attribute
Use of parent attribute is based on inheritance.

A child bean definition will use the bean class from the parent definition if none is specified, but can also override it. In the latter case, the child bean class must be compatible with the parent, that is it must accept the parent's property values.

A child bean definition will inherit constructor argument values, property values and method overrides from the parent, with the option to add new values. If any init-method, destroy-method and/or static factory method settings are specified, they will override the corresponding parent settings.

Example:

<bean id="beanId" class="pack.example.MyClass" abstract="true">
<property name="myProp" value="sample"/>
<bean/>
<bean id="child" class="pack.example.MyClass" parent="beanId">

<bean/> tag, singleton attribute
If we mark a bean as singleton then if we get it through its id, always the same object is referred. The created beans are implicit singletons. If we want to get a new instance when we refer to the bean, we have to set explicit to no singleton:

<bean id="child" class="pack.example.MyClass" singleton="false">