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:
Property | Explained in... |
---|---|
Class |
|
Name |
Naming beans |
Scope |
|
Constructor arguments |
|
Properties |
|
Automatic detection and linking mode |
|
Lazy initialization mode |
|
Initialization method |
|
Destruction method |
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.