property life injection example beans bean spring

life - ¿Cuál es la diferencia entre BeanPostProcessor y el método init/destroy en Spring?



spring injection example (7)

El componente pasa por varias etapas desde la creación hasta la destrucción en el contenedor Spring IoC. Es posible que necesite realizar alguna operación de inicialización de este componente antes de que se cree este componente. De manera similar, antes de la destrucción y eliminación del componente del contenedor IoC, algunas operaciones pueden ser necesarias. Para este marco Spring, permite definir métodos para la gestión del ciclo de vida de los componentes.

  • BeanPostProcessor interfaz BeanPostProcessor y el método que se especifica en el init-method son relevantes para las etapas de creación del componente.

Si el componente implementa la interfaz BeanPostProcessor , el contenedor Spring Io llama a los métodos de esta interfaz: postProcessBeforeInitialization() , postProcessAfterInitialization() . Después de esto, el componente está listo para su uso y permanecerá en el contenedor IoC antes de su destrucción. El método que se especifica en el atributo init-method se llamará entre estos dos métodos. (en realidad, antes del método afterPropertiesSet() de la interfaz InitializingBean , si el componente implementa esta interfaz).

  • DisposableBean interfaz DisposableBean y el método que se especifica en el destroy-method son relevantes para las etapas de destrucción del componente.

Si el componente implementa la interfaz DisposableBean , entonces el método Spring IoConvoca llamadas de esta interfaz: destroy() . Después de eso se llamará método que se especificó en el atributo destroy-method . Después de esto, el componente se destruye.

Es preferible utilizar los métodos enumerados en los atributos. Implementación de las interfaces BeanPostProcessor y DisposableBean hace que el acoplamiento entre los componentes y la API de Spring.

¿Cuál es la diferencia entre implementar la interfaz BeanPostProcessor y utilizar los atributos de método init / destroy en el archivo de configuración XML en Spring o implementar la interfaz InitializingBean / DisposableBean?


Esto se explica con bastante claridad en la documentación de Spring sobre los puntos de extensión del contenedor .

La interfaz BeanPostProcessor define los métodos de devolución de llamada que puede implementar para proporcionar su propia lógica de instanciación (o anular la predeterminada del contenedor), la lógica de resolución de dependencia, y demás. Si desea implementar alguna lógica personalizada después de que el contenedor Spring finalice la creación de instancias, la configuración y la inicialización de un bean, puede conectar una o más implementaciones de BeanPostProcessor.

Así que, en esencia, el método postProcessBeforeInitialization definido en BeanPostProcessor se llama (como su nombre indica) antes de la inicialización de los beans y asimismo se llama a postProcessAfterInitialization después de la inicialización del bean.

La diferencia con @PostConstruct , InitializingBean y el método de init personalizado es que estos se definen en el bean en sí. Su pedido se puede encontrar en la sección Combinación de mecanismos del ciclo de vida de la documentación de primavera.

Así que, básicamente, BeanPostProcessor se puede usar para hacer una lógica de creación de instancias personalizada para varios beans, mientras que los otros se definen en base a porotos.


Las respuestas anteriores explican claramente algunos de los aspectos más importantes.

Además de eso, también es importante comprender que tanto beanPostProcessor como los métodos init y destroy son parte del ciclo de vida de Spring Bean.

La clase BeanPostProcessor tiene dos métodos.

1) postProcessBeforeInitialization - como el nombre dice claramente que se usa para asegurarse de que se tomen las acciones necesarias antes de la inicialización. por ejemplo, desea cargar ciertos archivos de propiedades / leer datos de la fuente / servicio remoto.

2) postProcessAfterInitialization: cualquier cosa que desee hacer después de la inicialización antes de que se le dé referencia a la aplicación.

La secuencia de los métodos cuestionados en el ciclo de vida de la siguiente manera:

1) BeanPostProcessor.postProcessBeforeInitialization ()

2) init ()

3) BeanPostProcessor.postProcessAfterInitialization ()

4) destruir ()

Puede verificar esto escribiendo un ejemplo simple con sysout y verificando su secuencia.


Y una diferencia principal más es InitializingBean, los métodos afterPropertiesSet () y destory () relacionados con DisposableBean no aceptaron ningún parámetro ni tampoco el tipo de devolución, por lo que no implementamos ninguna lógica personalizada. Pero al llegar a los métodos BeanPostProcess postProcessBeforeInitialization (Object bean, String beanName) y postProcessAfterInitilization (Object bean, String beanName) aceptamos estos dos parámetros y devolvemos type también Object para que podamos escribir lógicas de inicialización así como también cualquier inicio de sesión personalizado basado en el paso frijol...

Estos dos métodos de devolución de llamada incluyen el ciclo de vida del frijol y los siguientes son el ciclo de vida de la siguiente manera

1) BeanPostProcessor.postProcessBeforeInitilazation ()

2) @postConstruct o InitializingBean.afterPropertiesSet () o método de inicialización que es
definiendo en xml / * aquí también está siguiendo el mismo oredr si hay tres formas disponibles ** /

3) BeanPostProcessor.postProcessAfterInitialization ()

4) @preDestroy o DisposibleBean.destroy () o método de destrucción que está definiendo en xml / * aquí también está siguiendo el mismo oredr si hay tres formas disponibles ** /


a) Se llamará a postProcessBeforeInitialization () antes de la inicialización del bean.

b) Una vez que el bean se inicializa, los diferentes métodos de devoluciones de llamada se invocan en el siguiente orden según los documentos de Spring:

  1. Métodos anotados con @PostConstruct
  2. afterPropertiesSet () según lo definido por la interfaz de devolución de llamada InitializingBean
  3. método init definido a través del XML.

La diferencia principal es que se invocan los 3 métodos anteriores una vez completada la inicialización mediante el método postProcessBeforeInitialization ().

Una vez que estos métodos se completan, se llamará al método postProcessAfterInitialization () y luego se invocarán los métodos de destrucción en el mismo orden:

  1. Métodos anotados con @PreDestroy

  2. destroy () según lo definido por la interfaz de devolución de llamada de DisposableBean

  3. método destroy () definido a través del XML.


BeanPostProcessor : BeanPostProcessor le da la oportunidad de procesar una instancia de un bean creado por el contenedor de IoC después de su creación de instancias y luego nuevamente después de que se haya producido el evento de ciclo de vida de inicialización en la instancia. Puede usar esto para procesar los campos que se establecieron, realizar la validación en un bean o incluso buscar valores desde un recurso remoto para establecerlos en el bean como valores predeterminados.

BeanPostProcessors y cualquier beans de los que dependen se instancian antes que cualquier otro beans en el contenedor. Una vez que se crean las instancias y se ordenan, se usan para procesar todos los otros beans a medida que el contenedor IoC crea una instancia. Los diferentes proponentes AOP de Spring para el almacenamiento en caché, transacciones, etc., son todos aplicados por BeanPostProcessors. Por lo tanto, cualquier BeanPostProcessor que cree no es elegible para los proxies AOP. Dado que los proxies AOP se aplican de esta manera, es posible que aún no se haya aplicado un proxy AOP a la instancia, por lo que se debe tener cuidado si esto afectará el procesamiento posterior.

Método init / destroy : en Spring, puede usar init-method y destroy-method como atributo en el archivo de configuración de beans para que Bean realice ciertas acciones luego de la inicialización y destrucción.

Aquí hay un ejemplo para mostrarle cómo usar init-method y destroy-method.

package com.xyz.customer.services; public class CustomerService { String message; public String getMessage() { return message; } public void setMessage(String message) { this.message = message; } public void initIt() throws Exception { System.out.println("Init method after properties are set : " + message); } public void cleanUp() throws Exception { System.out.println("Spring Container is destroy! Customer clean up"); } }

<beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd">

<bean id="customerService" class="com.xyz.customer.services.CustomerService" init-method="initIt" destroy-method="cleanUp"> <property name="message" value="i''m property message" /> </bean>


Los métodos de devolución de llamada Init y Destruir son parte de las fases del ciclo de vida de Spring Bean. El método init se ejecutará después de la instanciación de bean. Del mismo modo, el método de destrucción se ejecutará antes de la finalización del frijol.

Podemos implementar esta funcionalidad utilizando las interfaces de implementación InitializingBean y DisposableBean , o usando las anotaciones @postconstruct y @predestroy , o declarando el <bean> con los atributos init-method y destroy-method .

La interfaz BeanPostProcessor se usa para ampliar la funcionalidad del framework si se desea realizar cualquier configuración de inicialización previa y posterior al bean por contenedor de primavera.

Por ejemplo : de forma predeterminada, Spring no tendrá conocimiento de la anotación @PostConstruct y @PreDestroy . Para habilitarlo, tenemos que registrar CommonAnnotationBeanPostProcessor o especificar el <context:annotation-config /> en el archivo de configuración de bean. Aquí CommonAnnotationBeanPostProcessor es BeanPostProcessor implementación predefinida de BeanPostProcessor para las anotaciones. Me gusta:

@Required habilita la herramienta de procesamiento RequiredAnnotationBeanPostProcessor
@Autowired habilita la herramienta de procesamiento AutowiredAnnotationBeanPostProcessor