Obtener Spring Bean del contexto de aplicación de terceros correctamente

Buenas tardes, Khabrovites!

En este artículo, propongo discutir uno de los problemas que a menudo se encuentran en los proyectos que usan el marco Spring. El problema descrito en este artículo surge debido a uno de los errores típicos en las configuraciones de resorte. No es necesario intentar cometer tal error en la configuración y, por lo tanto, este error es bastante común.

Planteamiento del problema

El problema presentado en este artículo está relacionado con la configuración incorrecta de beans en el contexto de aplicación actual, que se toman de otros contextos de aplicación. Tal problema puede surgir en una aplicación industrial grande, que consiste en muchos frascos, cada uno de los cuales tiene su propio contexto de aplicación que contiene frijoles de primavera.

Como resultado de una configuración incorrecta, obtenemos varias copias de beans con un estado impredecible, incluso si tienen el alcance singleton. Además, la copia irreflexiva de beans puede conducir al hecho de que se crearán más de una docena de copias de todos los beans de cualquier jar en la aplicación, que está plagada de problemas de rendimiento de la aplicación y un aumento en el tiempo de inicio de la aplicación.

Un ejemplo de uso de un bean desde un contexto de aplicación externa en el actual

Imagine que estamos desarrollando uno de los módulos de aplicación, en el que hay muchos otros módulos, y que cada uno de ellos tiene su propio contexto de aplicación. Dicha aplicación debe tener un módulo en el que se creen instancias del contexto de aplicación de todos los módulos de aplicación.



Supongamos que, en el contexto de la aplicación de uno de los módulos externos, se crea una instancia del bean de la clase NumberGenerator, que queremos obtener en nuestro módulo. Supongamos también que la clase NumberGenerator se encuentra en el paquete org.example.kruchon.generators, que almacena algunas clases que generan valores.



Este bean tiene un estado: el campo int count.

package org.example.kruchon.calculators public class NumberGenerator { private int count = 0; public synchronized int next() { return count++; } } 

Se crea una instancia de este bean en la subconfiguración GeneratorsConfiguration.

 @Configuration public class GeneratorsConfiguration { @Bean public NumberGenerator numberGenerator() { return new NumberGenerator(); } ... } 

También en el contexto de la aplicación externa, hay una configuración principal en la que se importan todas las subconfiguraciones del módulo externo.

 @Configuration @Import({GeneratorsConfiguration.class, ...}) public class ExternalContextConfiguration { ... } 

Ahora daré algunos ejemplos en los que el bean singleton de la clase NumberGenerator está configurado incorrectamente en la configuración del contexto de la aplicación actual.

Configuración incorrecta 1. Importar la configuración principal del contexto de la aplicación externa

La peor decisión que podría ser.

 @Configuration @Import(ExternalContextConfiguration.class) public class CurrentContextConfiguration { ... } 

• La aplicación vuelve a crear todas las instancias de beans desde el contexto de la aplicación externa. En otras palabras, se crea una copia de todo el módulo externo, lo que afecta el consumo de memoria, el rendimiento y el tiempo de inicio de la aplicación.
• Obtenga una copia de NumberGenerator en el contexto actual de la aplicación. Una copia de NumberGenerator tiene su propio valor para el campo de recuento, inconsistente con la primera instancia de NumberGenerator. Esta inconsistencia da lugar a errores difíciles de depurar en la aplicación.

Configuración incorrecta 2. Subconfiguración de importación del contexto de aplicación externa

La segunda opción es incorrecta y a menudo se encuentra en la práctica.

 @Configuration @Import(GeneratorsConfiguration.class) public class CurrentContextConfiguration { ... } 

En esta realización, ya no se crea una copia completa del módulo externo, sin embargo, nuevamente obtenemos el segundo bean de la clase NumberGenerator.

Configuración incorrecta 3. Busque la inyección directamente en el bean, donde queremos usar NumberGenerator

 public class OrderFactory { private final NumberGenerator numberGenerator; public OrderFactory() { ApplicationContext externalApplicationContext = getExternalContext(); numberGenerator = externalApplicationContext.getBean(NumberGenerator.class); } public Order create() { Order order = new Order(); int id = numberGenerator.next(); order.setId(id); order.setCreatedDate(new Date()); return order; } private ApplicationContext getExternalContext(){ ... } } 

En este método, la duplicación de un bean que tiene el alcance singleton puede considerarse resuelta. De hecho, ahora reutilizamos el bean de otro contexto de aplicación y no lo recreamos.

Pero de esta manera:

1. Complica la clase desarrollada y sus pruebas unitarias.
2. Excluye la implementación automática del bean de la clase NumberGenerator en los beans del módulo actual.
3. No es habitual usar lookUp para inyectar un bean singleton en casos generales.

Por lo tanto, dicha solución es más una solución torpe que una solución racional a un problema.

Considere cómo configurar correctamente un bean desde un contexto de aplicación externa.

Solución 1. Obtenga el bean desde el contexto de la aplicación externa en la configuración

Este método es muy similar al 3er ejemplo de una configuración incorrecta con una diferencia: obtenemos un bean haciendo una búsqueda desde el contexto externo en la configuración, y no directamente en el bean.

 @Configuration public class CurrentContextConfiguration { @Bean public NumberGenerator numberGenerator() { ApplicationContext externalApplicationContext = getExternalContext(); return externalApplicationContext.getBean(NumberGenerator.class); } private ApplicationContext getExternalContext(){ ... } } 

Ahora podemos incrustar automáticamente este bean en beans desde nuestro propio módulo.

Solución 2. Haga que el contexto de la aplicación externa sea primario

Es probable que la funcionalidad del módulo actual amplíe la funcionalidad del externo. Puede haber un caso cuando en uno de los módulos externos se desarrollan beans auxiliares comunes a toda la aplicación, y en otros módulos se usan estos beans. En este caso, es lógico indicar que el módulo externo es padre del anterior. En este caso, todo el bean del módulo principal se puede usar en el módulo actual, y luego el bean del módulo principal no necesita configurarse en la configuración del contexto de la aplicación actual.

Es posible especificar una relación principal al crear una instancia de contexto utilizando el constructor con el parámetro principal:

 public AbstractApplicationContext(ApplicationContext parent) { ... } 

O usa el setter:

 public void setParent(ApplicationContext parent) { ... } 

Si el contexto de la aplicación se declara en xml, podemos usar el constructor:

 public ClassPathXmlApplicationContext(String[] configLocations, ApplicationContext parent) throws BeansException { ... } 

Conclusión

Por lo tanto, tenga cuidado al configurar beans de primavera, siga las recomendaciones dadas en el artículo e intente no copiar los beans que tienen alcance singleton. Estaré encantado de responder a sus preguntas!