Course Module 5. Spring - Lecture: What is Spring Bean

The Spring IoC container manages one or more beans. These beans are created using configuration metadata that you provide to the container (for example, as XML <bean/> definitions).

In the container itself, these bean definitions are represented in in the form of BeanDefinition objects, which contain (among other information) the following metadata:

The fully qualified class name with package designation: typically this is the actual implementation class of the bean being defined .
Bean behavioral configuration elements that define how the bean should behave in the container (scope, lifecycle callbacks, and so on).
Links to other beans that are necessary for its operation. These references are also called collaborators or dependencies.
Other configuration parameters that need to be set on the newly created object, such as the pool size limit or the number of connections, used in the bean that manages the connection pool.

This metadata is translated into a set of properties that make up the definition of each bean. The following table describes these properties:

Table 1. Bean definition
Property	Explained in...
Class	Creating beans
Name	Naming beans
Scope	Bean scopes
Constructor arguments	Dependency Injection
Properties	Dependency Injection
Automatic detection and linking mode	Interacting objects with automatic detection and binding
Lazy initialization mode	Beans with lazy initialization
Initialization method	Initialization callbacks
Destruction method	Destruction callbacks

In addition to bean definitions, which contain information about how to create a particular bean, ApplicationContext implementations also allow you to register existing objects that are created outside the container (by users). This can be done by accessing the BeanFactory ApplicationContext through the getBeanFactory() method, which returns an implementation of the DefaultListableBeanFactory. DefaultListableBeanFactory supports this registration through the registerSingleton(..) and registerBeanDefinition(..) methods. However, typical applications work exclusively with beans defined using standard bean definition metadata.

Bean metadata and manually provided single instances should be registered as soon as possible so that the container can process them correctly during automatic detection and binding and other introspection steps. While overriding existing metadata and existing singleton instances is supported to some extent, registering new beans at runtime (at the same time as direct factory access) is not officially supported and may result in concurrency exceptions, inconsistent state in the bean container, or both.

Naming beans

Each bean has one or more identifiers. These identifiers must be unique within the container in which the bean resides. Beans usually have only one identifier. However, if more than one is required, additional ones can be considered aliases.

XML-based configuration metadata uses the id attribute, the name attribute, or both to specify identifiers Bina. The id attribute allows you to specify only one identifier. Typically these names are alphanumeric ('myBean', 'someService', etc.), but they can also contain special characters. If you want to enter other aliases for the bean, you can also specify them in the name attribute, separated by a comma (,), semicolon (; ) or space. Historical note: In versions prior to Spring 3.1, the id attribute was defined as a type xsd:ID, which limited the use of symbols. Since version 3.1, it is defined as type xsd:string. Note that the uniqueness of the id bean is still enforced by the container, but not by the XML parsers.

You do not need to specify name or id for the bean. If you do not explicitly specify name or id, the container will generate a unique name for this bean. However, if you want to reference this bean by name using a ref element or a Service Locator style search, you must specify the name. The reasons for not specifying a name are related to the use of internal beans and interacting objects with automatic discovery and binding.

Bean Naming Conventions

The convention is to use the standard Java convention for naming instance fields when naming beans. That is, bean names begin with a lowercase letter and continue in camelCase (camel) case. Examples of such names are accountManager, accountService, userDao, loginController and so on.

Consistent bean naming makes the configuration easier to read and understand. Also, if you use AOP in Spring, this is very helpful when applying advice to a set of beans associated by name.

By scanning components along the classpath, Spring generates bean names for unnamed components, following the rules described earlier: essentially taking a simple class name and converting its leading character to lowercase. However, in the (unusual) special case where there is more than one character and the first and second characters are in upper case, the original case is preserved. These are the same rules as defined in java.beans.Introspector.decapitalize (which Spring uses here).

Assigning an alias to a bean outside of the bean definition

In The bean definition itself can specify more than one name for the bean, using a combination of one name specified by the id attribute and any number of other names in the name attribute. These names can be equivalent aliases for the same bean and are useful in some situations, such as when each component in an application references a common dependency using a bean name specific to that component.

However, setting all aliases in which the actual bean is defined is not always sufficient. Sometimes it is desirable to provide an alias for a bean that is defined elsewhere. This is typically the case in large systems where the configuration is divided between each subsystem and each subsystem has its own set of object definitions. In XML-based configuration metadata, you can use the <alias/> element for this. The following example shows how to do this:

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

In this case, a bean (in the same container) with the name fromName - after using this alias definition - may be referred to as toName.

For example, configuration metadata for Subsystem A may refer to a DataSource named subsystemA-dataSource. Configuration metadata for subsystem B can reference a DataSource named subsystemB-dataSource. When you create a main application that uses both of these subsystems, the main application accesses the DataSource named myApp-dataSource. To ensure that all three names refer to the same object, you can add the following alias definitions to the configuration metadata:


<alias name ="myApp-dataSource" alias="subsystemA-dataSource"/>
<alias name="myApp-dataSource" alias="subsystemB-dataSource"/>

Every component and host application can now access the dataSource via a name that is unique and guaranteed not to conflict with any other definition (effectively creating a namespace), but they still refer to the same bean.

Java configuration

If you are using Javaconfiguration, the @Bean annotation can be used to provide aliases.