A bean definition can contain a lot of configuration information,
including constructor arguments, property values, and container-specific
information such as initialization method, static factory method name, and
so on. A child bean definition inherits configuration data from a parent
definition. The child definition can override some values, or add others,
as needed. Using parent and child bean definitions can save a lot of
typing. Effectively, this is a form of templating.
If you work with an
A child bean definition uses 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 inherits scope, constructor argument values, property values, and method overrides from the parent, with the option to add new values. Any scope, initialization method, destroy method, and/or
The remaining settings are always taken from the child definition: depends on, autowire mode, dependency check, singleton, lazy init.
The preceding example explicitly marks the parent bean definition as abstract by using the
The parent bean cannot be instantiated on its own because it is incomplete, and it is also explicitly marked as
If you work with an
ApplicationContext
interface programmatically, child bean definitions are represented by the
ChildBeanDefinition
class. Most users do not work
with them on this level, instead configuring bean definitions
declaratively in something like the
ClassPathXmlApplicationContext
. When you use
XML-based configuration metadata, you indicate a child bean definition by
using the parent
attribute, specifying the parent bean
as the value of this attribute.
<bean id="inheritedTestBean" abstract="true" class="org.springframework.beans.TestBean"> <property name="name" value="parent"/> <property name="age" value="1"/> </bean> <bean id="inheritsWithDifferentClass" class="org.springframework.beans.DerivedTestBean" parent="inheritedTestBean" init-method="initialize"> <property name="name" value="override"/> <!-- the age property value of 1 will be inherited from parent --> </bean>
A child bean definition uses 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 inherits scope, constructor argument values, property values, and method overrides from the parent, with the option to add new values. Any scope, initialization method, destroy method, and/or
static
factory method settings that you specify will
override the corresponding parent settings.The remaining settings are always taken from the child definition: depends on, autowire mode, dependency check, singleton, lazy init.
The preceding example explicitly marks the parent bean definition as abstract by using the
abstract
attribute. If the parent
definition does not specify a class, explicitly marking the parent bean
definition as abstract
is required, as follows:
<bean id="inheritedTestBeanWithoutClass" abstract="true"> <property name="name" value="parent"/> <property name="age" value="1"/> </bean> <bean id="inheritsWithClass" class="org.springframework.beans.DerivedTestBean" parent="inheritedTestBeanWithoutClass" init-method="initialize"> <property name="name" value="override"/> <!-- age will inherit the value of 1 from the parent bean definition--> </bean>
The parent bean cannot be instantiated on its own because it is incomplete, and it is also explicitly marked as
abstract
. When a definition is
abstract
like this, it is usable only as a pure
template bean definition that serves as a parent definition for child
definitions. Trying to use such an abstract
parent bean
on its own, by referring to it as a ref property of another bean or doing
an explicit getBean()
call with the parent bean
id, returns an error. Similarly, the container's internal
preInstantiateSingletons()
method ignores bean
definitions that are defined as abstract.Note | |
---|---|
ApplicationContext pre-instantiates all
singletons by default. Therefore, it is important (at least for
singleton beans) that if you have a (parent) bean definition which you
intend to use only as a template, and this definition specifies a class,
you must make sure to set the abstract attribute to
true, otherwise the application context will
actually (attempt to) pre-instantiate the abstract
bean. |
No comments:
Post a Comment