El contenedor Spring IoC administra uno o más beans. Estos beans se crean utilizando metadatos de configuración que
usted proporciona al contenedor (por ejemplo, como definiciones XML <bean/>
).
En el propio
contenedor, estas definiciones de beans se representan en forma de objetos BeanDefinition
, que
contienen (entre otra información) los siguientes metadatos:
El nombre de clase completo con la designación del paquete: normalmente, esta es la clase de implementación real del bean que se está definiendo.
Elementos de configuración de comportamiento del bean que definen cómo debe comportarse el bean en el contenedor (alcance, devoluciones de llamadas del ciclo de vida, etc.) ).
Enlaces a otros beans que son necesarios para su funcionamiento. Estas referencias también se denominan colaboradores o dependencias.
Se utilizan otros parámetros de configuración que deben establecerse en el objeto recién creado, como el límite de tamaño del grupo o el número de conexiones. en el bean que administra el grupo de conexiones.
Estos metadatos se traducen en un conjunto de propiedades que conforman la definición de cada bean. La siguiente tabla describe estas propiedades:
Property | Explained in... |
---|---|
Class |
|
Name |
Naming beans |
Scope |
|
Constructor arguments |
|
Properties |
|
Automatic detection and linking mode |
|
Lazy initialization mode |
|
Initialization method |
|
Destruction method |
Además de las definiciones de beans, que contienen información sobre cómo crear un bean en particular, las
implementaciones de ApplicationContext
también le permiten registrar objetos existentes creados fuera
del contenedor (por los usuarios). Esto se puede hacer accediendo a BeanFactory
ApplicationContext a
través del método getBeanFactory()
, que devuelve una implementación de
DefaultListableBeanFactory
. DefaultListableBeanFactory
admite este registro a través de
los métodos registerSingleton(..)
y registerBeanDefinition(..)
. Sin embargo, las
aplicaciones típicas funcionan exclusivamente con beans definidos utilizando metadatos de definición de beans
estándar.
Los metadatos de beans y las instancias individuales proporcionadas manualmente deben registrarse lo antes posible. como sea posible para que el contenedor pueda procesarlos correctamente durante la detección y vinculación automáticas y otros pasos de introspección. Si bien se admite hasta cierto punto la anulación de metadatos existentes y de instancias singleton existentes, el registro de nuevos beans en tiempo de ejecución (al mismo tiempo que el acceso directo a la fábrica) no se admite oficialmente y puede dar como resultado excepciones de concurrencia, estados inconsistentes en el contenedor de beans o ambos. .
Nombrar beans
Cada bean tiene uno o más identificadores. Estos identificadores deben ser únicos dentro del contenedor en el que reside el bean. Los frijoles suelen tener un solo identificador. Sin embargo, si se requiere más de uno, los adicionales pueden considerarse alias.
Los metadatos de configuración basados en XML utilizan
el atributo id
y el atributo name
. , o ambos para especificar los identificadores Bina. El
atributo id
le permite especificar solo un identificador. Normalmente estos nombres son alfanuméricos
('myBean', 'someService', etc.), pero también pueden contener caracteres especiales. Si desea ingresar otros alias
para el bean, también puede especificarlos en el atributo name
, separados por una coma (,
),
punto y coma (;
) o espacio. Nota histórica: en versiones anteriores a Spring 3.1, el atributo
id
se definía como un tipo xsd:ID
, lo que limitaba el uso de símbolos. Desde la
versión 3.1, se define como tipo xsd:string
. Tenga en cuenta que el contenedor sigue aplicando la
unicidad del bean id
, pero no los analizadores XML.
No es necesario especificar
name
o id
para el bean. Si no especifica explícitamente name
o
id
, el contenedor generará un nombre único para este bean. Sin embargo, si desea hacer referencia a
este bean por su nombre utilizando un elemento ref
o una búsqueda de estilo Localizador de servicios,
debe especificar el nombre. Los motivos para no especificar un nombre están relacionados con el uso de beans
internos y objetos que interactúan con descubrimiento y enlace automáticos.
java.beans.Introspector.decapitalize
(que Spring usa aquí).
Asignación de un alias a un bean fuera de la definición del bean
En La definición del bean en sí
puede especificar más de un nombre para el bean, usando una combinación de un nombre especificado por el atributo
id
y cualquier número de otros nombres en el name
atributo. Estos nombres pueden ser
alias equivalentes para el mismo bean y son útiles en algunas situaciones, como cuando cada componente de una
aplicación hace referencia a una dependencia común utilizando un nombre de bean específico para ese componente.
Sin embargo, configurar todos los alias en el que se define el bean real no siempre es suficiente. A veces es
deseable proporcionar un alias para un bean que esté definido en otro lugar. Este suele ser el caso en sistemas
grandes donde la configuración se divide entre cada subsistema y cada subsistema tiene su propio conjunto de
definiciones de objetos. En los metadatos de configuración basados en XML, puede utilizar el elemento <alias/>
para esto. El siguiente ejemplo muestra cómo hacer esto:
<alias name="fromName" alias="toName"/>
En este caso, un bean (en el mismo contenedor) con el nombre fromName
- después de usar esta
definición de alias - puede denominarse toName
.
Por ejemplo, los metadatos de configuración para el Subsistema A pueden referirse a una fuente de datos denominada
subsystemA-dataSource
. Los metadatos de configuración para el subsistema B pueden hacer referencia a una fuente de datos denominada
subsystemB-dataSource
. Cuando crea una aplicación principal que utiliza ambos subsistemas, la
aplicación principal accede al origen de datos denominado myApp-dataSource
. Para asegurarse de que los
tres nombres hagan referencia al mismo objeto, puede agregar las siguientes definiciones de alias a los metadatos de
configuración:
<alias name ="myApp-dataSource" alias="subsystemA-dataSource"/>
<alias name="myApp-dataSource" alias="subsystemB-dataSource"/>
Cada componente y aplicación host ahora puede acceder a dataSource a través de un nombre que es único y que garantiza que no entrará en conflicto con ninguna otra definición (creando efectivamente un espacio de nombres), pero aún así se refiere al mismo bean.