Quelle est la différence entre BeanPostProcessor et la méthode init/destroy dans Spring?

Question

Quelle est la différence entre l'implémentation de l'interface BeanPostProcessor et l'utilisation des attributs de la méthode init/destroy dans le fichier de configuration XML dans Spring et l'implémentation de l'interface InitializingBean/DisposableBean?

Answer 1

Ceci est assez clairement expliqué dans la documentation de Spring sur les Points d'extension de conteneur . 

L’interface BeanPostProcessor définit les méthodes de rappel que vous pouvez implémenter pour fournir le vôtre (ou remplacer la valeur par défaut du conteneur) logique d'instanciation, logique de résolution de dépendance, etc. Si vous vouloir implémenter une logique personnalisée après le conteneur Spring termine l’instanciation, la configuration et l’initialisation d’un bean, vous pouvez branchez une ou plusieurs implémentations de BeanPostProcessor.

Donc, essentiellement, la méthode postProcessBeforeInitialization définie dans BeanPostProcessor est appelée (comme son nom l'indique) avant l'initialisation des beans, de même que postProcessAfterInitialization est appelée après l'initialisation du bean. 

La différence par rapport aux méthodes @PostConstruct, InitializingBean et custom init est que celles-ci sont définies sur le bean lui-même. Vous trouverez leur ordre dans la section Combinaison de mécanismes de cycle de vie de la documentation de printemps.

Donc, fondamentalement, le BeanPostProcessor peut être utilisé pour créer une logique d'instanciation personnalisée pour plusieurs beans alors que les autres sont définis par bean.

Answer 2

Les réponses ci-dessus expliquent clairement certains des aspects très importants.

En dehors de cela, il est également important de comprendre que les méthodes beanPostProcessor et init and destroy font partie du cycle de vie du bean Spring.

La classe BeanPostProcessor a deux méthodes.

1) postProcessBeforeInitialization - comme son nom l'indique clairement, il est utilisé pour s'assurer que les actions requises sont effectuées avant l'initialisation. par exemple. vous voulez charger certaines données du fichier de propriété/lire à partir de la source/du service distant.

2) postProcessAfterInitialization - tout ce que vous voulez faire après l'initialisation avant que la référence du bean ne soit donnée à l'application.

Séquence des méthodes interrogées dans le cycle de vie comme suit:

1) BeanPostProcessor.postProcessBeforeInitialization ()

2) init ()

3) BeanPostProcessor.postProcessAfterInitialization () 

4) détruire ()

Vous pouvez vérifier cela en écrivant un exemple simple avec sysout et en vérifiant leur séquence.

Answer 3

Les méthodes de rappel Init et Destroy font partie des phases du cycle de vie du haricot printanier. La méthode init sera exécutée après l’instanciation du bean. De même, la méthode destroy sera exécutée avant la finalisation du bean.

Nous pouvons implémenter cette fonctionnalité en implémentant les interfaces InitializingBean et DisposableBean, ou en utilisant les annotations @postconstruct et @predestroy, ou déclarer le <bean> avec les attributs init-method et destroy-method. 

Interface BeanPostProcessor est utilisé pour étendre la fonctionnalité du framework si vous souhaitez effectuer une configuration quelconque de l'initialisation pré et post bean effectuée par le conteneur spring. 

Par exemple : Par défaut, Spring n'aura pas connaissance des annotations @PostConstruct et @PreDestroy. Pour l'activer, nous devons soit enregistrer CommonAnnotationBeanPostProcessor, soit spécifier le <context:annotation-config /> dans le fichier de configuration du bean. Ici CommonAnnotationBeanPostProcessor est une implémentation BeanPostProcessor prédéfinie pour les annotations. Comme: 

@Required active l'outil de traitement RequiredAnnotationBeanPostProcessor
@Autowired active l'outil de traitement AutowiredAnnotationBeanPostProcessor

Answer 4

Et une autre différence principale est InitializingBean, liée aux méthodes afterPropertiesSet () & destory () associées, qui n’acceptaient pas les paramètres et retournaient le type, ainsi nous n’avons implémenté aucune logique personnalisée . , String beanName) et postProcessAfterInitilization (Object bean, String beanName) acceptent ces deux paramètres et renvoient le type ainsi Object afin que nous puissions écrire des logiques d'initialisation ainsi que toute connexion personnalisée en fonction du bean ...

Ces deux méthodes de rappel incluent le cycle de vie du haricot et le cycle de vie suivant est le suivant 

1) BeanPostProcessor.postProcessBeforeInitilazation ()

2) @postConstruct ou InitializingBean.afterPropertiesSet () ou la méthode d’initialisation qui est
définition en xml / * ici aussi, il suit le même oredr si trois moyens sont disponibles ** /

3) BeanPostProcessor.postProcessAfterInitialization ()

4) @preDestroy ou DisposibleBean.destroy () ou la méthode destroy qui définit en xml / * ici aussi, il suit le même oredr si trois moyens sont disponibles ** /

Answer 5

Juste un petit complément à toutes les réponses ci-dessus: Si vous avez une logique générique, une logique commune qui doit être appliquée universellement à tous vos beans Spring, telle que l’injection d’un enregistreur dans vos beans, la définition d’un fichier de propriétés, la définition par défaut valeurs aux champs de vos haricots par la réflexion; vous pouvez mettre cette logique dans UN seul emplacement: les callbacks @Overriden (par exemple: postProcessBeforeInitialization(Object arg0, String arg1) si vous implémentez l'interface BeanPostProcessor); au lieu de dupliquer la même logique sur tous vos beans.

Answer 6

Le composant passe par plusieurs étapes, de la création à la destruction dans le conteneur Spring IoC. Il peut être nécessaire d'effectuer certaines opérations d'initialisation de ce composant avant que ce composant ne soit créé. De même, avant la destruction et le retrait du composant du conteneur IoC, certaines opérations peuvent être nécessaires. Pour cette structure, Spring permet de définir des méthodes pour la gestion du cycle de vie des composants.

• L'interface BeanPostProcessor et la méthode spécifiée dans le init-method sont pertinentes pour les étapes de la création du composant.

Si le composant implémente l'interface BeanPostProcessor, le conteneur Spring IoC appelle les méthodes de cette interface: postProcessBeforeInitialization(), postProcessAfterInitialization(). Après cela, le composant est prêt à être utilisé et restera dans le conteneur IoC avant sa destruction. La méthode spécifiée dans l'attribut init-method sera appelée entre ces deux méthodes. (en réalité, avant la méthode afterPropertiesSet() de l'interface InitializingBean, si le composant implémente cette interface).

• L'interface DisposableBean et la méthode spécifiée dans le destroy-method sont pertinentes pour les étapes de la destruction du composant.

Si le composant implémente l'interface DisposableBean, la méthode d'appels du conteneur Spring IoC de cette interface est la suivante: destroy(). Après cela sera appelée méthode spécifiée dans l'attribut destroy-method. Après cela, le composant est détruit.

Il est préférable d'utiliser les méthodes répertoriées dans les attributs. L'implémentation des interfaces BeanPostProcessor et DisposableBean permet le couplage entre les composants et l'API Spring.