From 2d9ced04b1d79090abc3f5587ad341ce4489af68 Mon Sep 17 00:00:00 2001 From: Chris Beams Date: Mon, 20 Jun 2011 06:48:36 +0000 Subject: [PATCH] Clarify BeanPostProcessor ordering rules in ref doc Issue: SPR-7550 --- .../src/beans-extension-points.xml | 28 ++++++++++++++++++- 1 file changed, 27 insertions(+), 1 deletion(-) diff --git a/spring-framework-reference/src/beans-extension-points.xml b/spring-framework-reference/src/beans-extension-points.xml index a65097150e..ece0f13728 100644 --- a/spring-framework-reference/src/beans-extension-points.xml +++ b/spring-framework-reference/src/beans-extension-points.xml @@ -33,7 +33,10 @@ implementing the Ordered interface too. For further details, consult the Javadoc for the BeanPostProcessor and - Ordered interfaces. + Ordered interfaces. See also the note below on + + programmatic registration of BeanPostProcessors + BeanPostProcessors operate on bean (or object) @@ -81,6 +84,29 @@ Bean post-processors can be deployed in the container just like any other beans. + + + Programmatically registering <interfacename>BeanPostProcessors + </interfacename> + + While the recommended approach for BeanPostProcessor + registration is through ApplicationContext + auto-detection (as described above), it is also + possible to register them programmatically + against an ApplicationContext using the + addBeanPostProcessor method. This can be useful + when needing to evaluate conditional logic before registration, or even + for copying bean post processors across contexts in a hierarchy. Note + however that BeanPostProcessors added + programmatically do not respect the Ordered + interface. Here it is the order of + registration that dictates the order of execution. Note also + that BeanPostProcessors registered + programmatically are always processed before those registered through + auto-detection, regardless of any explicit ordering. + + + <interfacename>BeanPostProcessors</interfacename> and AOP auto-proxying