2012-06-12 19 views
11

¿Tiene dos definiciones para un bean (con el mismo nombre y clase) válidas en Spring IOC?Definir el mismo bean de resorte dos veces con el mismo nombre

Tengo dos archivos de definición de beans incluidos en web.xml. Vea la muestra a continuación.

applicationContext-beans1.xml

<bean name="myWao" 
    class="com.beans.myBean">  
</bean> 

applicationContext-beans2.xml

<bean name="myWao" 
    class="com.beans.myBean">  
</bean> 

yo no estoy frente a cualquier problema hasta ahora. Pero, ¿esto posiblemente tendrá un impacto en el entorno real, que tendrá múltiples hilos y se agruparán?

Nota: Tanto los XMLs se cargan como soy capaz de utilizar los otros beans definidos (sólo una vez), tanto en el XMLs

+0

¿Ambos archivos xml están realmente cargados? –

+0

Sí. Ambos están cargados. – hop

+0

posible duplicado de [bean prioritario de Spring] (http://stackoverflow.com/questions/5849192/springs-overriding-bean) –

Respuesta

27

Es válido, pero se puede encontrar que un grano es anulado por el otro. Verá esto en los registros como

Overriding bean definition for... 

Este comportamiento le permite anular las definiciones de bean suministradas anteriormente. Afecta al ensamblaje estático de su aplicación, y no se relaciona con el enhebrado/agrupamiento como se sugiere en su pregunta.

Tenga en cuenta que la DefaultListableBeanFactory le permite configurar este comportamiento a través de setAllowBeanDefinitionOverriding()

+0

setAllowBeanDefinitionOverriding() debe hacerse antes. Si crea programáticamente el contexto de bean, asegúrese de utilizar un constructor con un parámetro de actualización establecido en falso y luego la carga de activación "manual". Esto funcionará incluso cuando sus granos de primavera se extiendan a través de múltiples archivos/contextos. De lo contrario, si habilita el registro DEBUG, verá entradas de registro como 'DEBUG osbfsDefaultListableBeanFactory - Reemplazando la definición de bean 'bean' con una definición equivalente: reemplazando ... [spring/config1.xml]] con ... ; definido en ... [spring/config2.xml]] ' –

6

Esto es válido y útil sobre todo cuando se trata de cambiar la implementación de un grano de terceros (me refiero, en la que no se le permite cambiar la implementación de un bean) y donde necesita proporcionar/configurar algunas propiedades adicionales (fusión) para el bean.

La anulación del bean depende del orden de las xmls que proporcione para compilar el ApplicationContext a través de web.xml o independiente. La última definición de bean ganará el juego.

Cuestiones relacionadas