2012-08-06 17 views
8

Digamos que tengo dos módulos. Uno es el núcleo y otro es el módulo de implementación dependiente del núcleo. Core es un archivo jar para esa guerra de módulo de implementación dependiente.redefinición de la configuración de frijol en la primavera

En el núcleo tengo un grano define como

<bean id="x" class="com.pokuri.X"> 
<property name="y" ref="y"/> 
<property name="z" ref="z"/> 
</bean> 

Y esa clase tiene un método de la siguiente manera

public class X{ 

    public void doSomeJob(){ 
    ....... 
    } 

} 

este método está siendo llamado desde algunas clases básicas. Ahora necesito alterar la lógica en ese método doSomeJob() de X según mi implementación dependiente del núcleo. Así, se crea una clase como esta

public class ExtX extends X{ 

    @override 
    public void doSomeJob(){ 
    // changed logic 
    } 

} 

y se define el grano con el mismo ID en otro archivo XML contexto de aplicación como esta.

<bean id="x" class="com.pokuri.ExtX"> 
    <property name="y" ref="y"/> 
    <property name="z" ref="z"/> 
</bean> 

y estamos construyendo contexto de aplicación con el parámetro contextConfigLocation contexto en web.xml especificando valor como classpath:springfolder.

Pero en la lógica central estoy obteniendo solo la instancia de beans centrales (es decir, instancia X) no ExtX. ¿Cómo podemos anular esa definición de bean y permitir que el sistema comience a usar la nueva definición de bean extendida?

Y oí que con la misma ID en diferentes archivos de contexto de la aplicación se anulará la primera definición de bean cargada con la definición de bean cargada más tarde. ¿Hay algún tipo de atributo priority en la definición de bean para permitir que ApplicationContext use la prioridad más alta para considerar uno de baja prioridad cuando se encuentran beans con la misma ID?

Respuesta

12

Una forma de anular la definición del bean es lo que ha indicado - definirlo con el mismo id varias veces y la última definición del bean con el mismo id es la que tiene efecto. Por lo tanto, si se asegura de que ExtX es el último cargado, debería funcionar, y para asegurarse de que puede hacerlo en su archivo war, en lugar de cargarlo diciendo classpath:springfolder, puede importar explícitamente la configuración central en el Spring de su guerra archivo de configuración y luego anulan el grano de esta manera:

<import resource="core-resource.xml"/> 
<bean id="x" class="com.pokuri.ExtX"> 
    <property name="y" ref="y"/> 
    <property name="z" ref="z"/> 
</bean> 

esto asegurará que el bean reemplazado es la que entra en vigor.

No hay campo de prioridad/orden que pueda utilizar aquí, si lo desea, puede cargar todas las definiciones de bean de un tipo proporcionando Map<String,X> como parámetro, y ordenarlo esperando una propiedad de la orden y uso de esa manera, pero hay mucho más trabajo para eso.

Un segundo enfoque se describe aquí: Overriding the bean defined in parent context in a child context

+0

intentará su acercamiento – Pokuri

+0

Por supuesto que funciona. ¿Pero es una buena práctica cubrir una definición por otra? Creo que es una especie de truco: / –

Cuestiones relacionadas