spring-framework / org.springframework.beans.factory.support / MergedBeanDefinitionPostProcessor

MergedBeanDefinitionPostProcessor

interface MergedBeanDefinitionPostProcessor : BeanPostProcessor

Post-processor callback interface for merged bean definitions at runtime. BeanPostProcessor implementations may implement this sub-interface in order to post-process the merged bean definition (a processed copy of the original bean definition) that the Spring BeanFactory uses to create a bean instance.

The #postProcessMergedBeanDefinition method may for example introspect the bean definition in order to prepare some cached metadata before post-processing actual instances of a bean. It is also allowed to modify the bean definition but only for definition properties which are actually intended for concurrent modification. Essentially, this only applies to operations defined on the RootBeanDefinition itself but not to the properties of its base classes.

Author
Juergen Hoeller

Since
2.5

See Also
org.springframework.beans.factory.config.ConfigurableBeanFactory#getMergedBeanDefinition

Functions

postProcessMergedBeanDefinition

abstract fun postProcessMergedBeanDefinition(beanDefinition: RootBeanDefinition, beanType: Class<*>, beanName: String): Unit

Post-process the given merged bean definition for the specified bean.

Inheritors

AutowiredAnnotationBeanPostProcessor

open class AutowiredAnnotationBeanPostProcessor : InstantiationAwareBeanPostProcessorAdapter, MergedBeanDefinitionPostProcessor, PriorityOrdered, BeanFactoryAware

org.springframework.beans.factory.config.BeanPostProcessor implementation that autowires annotated fields, setter methods and arbitrary config methods. Such members to be injected are detected through a Java 5 annotation: by default, Spring's Autowired and Value annotations.

Also supports JSR-330's javax.inject.Inject annotation, if available, as a direct alternative to Spring's own @Autowired.

Only one constructor (at max) of any given bean class may carry this annotation with the 'required' parameter set to true, indicating the constructor to autowire when used as a Spring bean. If multiple non-required constructors carry the annotation, they will be considered as candidates for autowiring. The constructor with the greatest number of dependencies that can be satisfied by matching beans in the Spring container will be chosen. If none of the candidates can be satisfied, then a default constructor (if present) will be used. An annotated constructor does not have to be public.

Fields are injected right after construction of a bean, before any config methods are invoked. Such a config field does not have to be public.

Config methods may have an arbitrary name and any number of arguments; each of those arguments will be autowired with a matching bean in the Spring container. Bean property setter methods are effectively just a special case of such a general config method. Config methods do not have to be public.

Note: A default AutowiredAnnotationBeanPostProcessor will be registered by the "context:annotation-config" and "context:component-scan" XML tags. Remove or turn off the default annotation configuration there if you intend to specify a custom AutowiredAnnotationBeanPostProcessor bean definition.

NOTE: Annotation injection will be performed before XML injection; thus the latter configuration will override the former for properties wired through both approaches.

In addition to regular injection points as discussed above, this post-processor also handles Spring's Lookup annotation which identifies lookup methods to be replaced by the container at runtime. This is essentially a type-safe version of getBean(Class, args) and getBean(String, args), See Lookup for details.

InitDestroyAnnotationBeanPostProcessor

open class InitDestroyAnnotationBeanPostProcessor : DestructionAwareBeanPostProcessor, MergedBeanDefinitionPostProcessor, PriorityOrdered, Serializable

org.springframework.beans.factory.config.BeanPostProcessor implementation that invokes annotated init and destroy methods. Allows for an annotation alternative to Spring's org.springframework.beans.factory.InitializingBean and org.springframework.beans.factory.DisposableBean callback interfaces.

The actual annotation types that this post-processor checks for can be configured through the "initAnnotationType" and "destroyAnnotationType" properties. Any custom annotation can be used, since there are no required annotation attributes.

Init and destroy annotations may be applied to methods of any visibility: public, package-protected, protected, or private. Multiple such methods may be annotated, but it is recommended to only annotate one single init method and destroy method, respectively.

Spring's org.springframework.context.annotation.CommonAnnotationBeanPostProcessor supports the JSR-250 javax.annotation.PostConstruct and javax.annotation.PreDestroy annotations out of the box, as init annotation and destroy annotation, respectively. Furthermore, it also supports the javax.annotation.Resource annotation for annotation-driven injection of named beans.

JmsListenerAnnotationBeanPostProcessor

open class JmsListenerAnnotationBeanPostProcessor : MergedBeanDefinitionPostProcessor, Ordered, BeanFactoryAware, SmartInitializingSingleton

Bean post-processor that registers methods annotated with JmsListener to be invoked by a JMS message listener container created under the cover by a org.springframework.jms.config.JmsListenerContainerFactory according to the attributes of the annotation.

Annotated methods can use flexible arguments as defined by JmsListener.

This post-processor is automatically registered by Spring's <jms:annotation-driven> XML element, and also by the EnableJms annotation.

Autodetects any JmsListenerConfigurer instances in the container, allowing for customization of the registry to be used, the default container factory or for fine-grained control over endpoints registration. See the EnableJms javadocs for complete usage details.

PersistenceAnnotationBeanPostProcessor

open class PersistenceAnnotationBeanPostProcessor : InstantiationAwareBeanPostProcessor, DestructionAwareBeanPostProcessor, MergedBeanDefinitionPostProcessor, PriorityOrdered, BeanFactoryAware, Serializable

BeanPostProcessor that processes javax.persistence.PersistenceUnit and javax.persistence.PersistenceContext annotations, for injection of the corresponding JPA resources javax.persistence.EntityManagerFactory and javax.persistence.EntityManager. Any such annotated fields or methods in any Spring-managed object will automatically be injected.

This post-processor will inject sub-interfaces of EntityManagerFactory and EntityManager if the annotated fields or methods are declared as such. The actual type will be verified early, with the exception of a shared ("transactional") EntityManager reference, where type mismatches might be detected as late as on the first actual invocation.

Note: In the present implementation, PersistenceAnnotationBeanPostProcessor only supports @PersistenceUnit and @PersistenceContext with the "unitName" attribute, or no attribute at all (for the default unit). If those annotations are present with the "name" attribute at the class level, they will simply be ignored, since those only serve as deployment hint (as per the Java EE specification).

This post-processor can either obtain EntityManagerFactory beans defined in the Spring application context (the default), or obtain EntityManagerFactory references from JNDI ("persistence unit references"). In the bean case, the persistence unit name will be matched against the actual deployed unit, with the bean name used as fallback unit name if no deployed name found. Typically, Spring's org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean will be used for setting up such EntityManagerFactory beans. Alternatively, such beans may also be obtained from JNDI, e.g. using the jee:jndi-lookup XML configuration element (with the bean name matching the requested unit name). In both cases, the post-processor definition will look as simple as this:

 <bean class="org.springframework.orm.jpa.support.PersistenceAnnotationBeanPostProcessor"/>
In the JNDI case, specify the corresponding JNDI names in this post-processor's "persistenceUnits" map, typically with matching persistence-unit-ref entries in the Java EE deployment descriptor. By default, those names are considered as resource references (according to the Java EE resource-ref convention), located underneath the "java:comp/env/" namespace. For example:
 <bean class="org.springframework.orm.jpa.support.PersistenceAnnotationBeanPostProcessor"> <property name="persistenceUnits"> <map/gt; <entry key="unit1" value="persistence/unit1"/> <entry key="unit2" value="persistence/unit2"/> </map/gt; </property> </bean>
In this case, the specified persistence units will always be resolved in JNDI rather than as Spring-defined beans. The entire persistence unit deployment, including the weaving of persistent classes, is then up to the Java EE server. Persistence contexts (i.e. EntityManager references) will be built based on those server-provided EntityManagerFactory references, using Spring's own transaction synchronization facilities for transactional EntityManager handling (typically with Spring's @Transactional annotation for demarcation and org.springframework.transaction.jta.JtaTransactionManager as backend).

If you prefer the Java EE server's own EntityManager handling, specify entries in this post-processor's "persistenceContexts" map (or "extendedPersistenceContexts" map, typically with matching persistence-context-ref entries in the Java EE deployment descriptor. For example:

 <bean class="org.springframework.orm.jpa.support.PersistenceAnnotationBeanPostProcessor"> <property name="persistenceContexts"> <map/gt; <entry key="unit1" value="persistence/context1"/> <entry key="unit2" value="persistence/context2"/> </map/gt; </property> </bean>
If the application only obtains EntityManager references in the first place, this is all you need to specify. If you need EntityManagerFactory references as well, specify entries for both "persistenceUnits" and "persistenceContexts", pointing to matching JNDI locations.

NOTE: In general, do not inject EXTENDED EntityManagers into STATELESS beans, i.e. do not use @PersistenceContext with type EXTENDED in Spring beans defined with scope 'singleton' (Spring's default scope). Extended EntityManagers are not thread-safe, hence they must not be used in concurrently accessed beans (which Spring-managed singletons usually are).

Note: A default PersistenceAnnotationBeanPostProcessor will be registered by the "context:annotation-config" and "context:component-scan" XML tags. Remove or turn off the default annotation configuration there if you intend to specify a custom PersistenceAnnotationBeanPostProcessor bean definition.

RequiredAnnotationBeanPostProcessor

open class RequiredAnnotationBeanPostProcessor : InstantiationAwareBeanPostProcessorAdapter, MergedBeanDefinitionPostProcessor, PriorityOrdered, BeanFactoryAware

org.springframework.beans.factory.config.BeanPostProcessor implementation that enforces required JavaBean properties to have been configured. Required bean properties are detected through a Java 5 annotation: by default, Spring's Required annotation.

The motivation for the existence of this BeanPostProcessor is to allow developers to annotate the setter properties of their own classes with an arbitrary JDK 1.5 annotation to indicate that the container must check for the configuration of a dependency injected value. This neatly pushes responsibility for such checking onto the container (where it arguably belongs), and obviates the need (in part) for a developer to code a method that simply checks that all required properties have actually been set.

Please note that an 'init' method may still need to implemented (and may still be desirable), because all that this class does is enforce that a 'required' property has actually been configured with a value. It does not check anything else... In particular, it does not check that a configured value is not null.

Note: A default RequiredAnnotationBeanPostProcessor will be registered by the "context:annotation-config" and "context:component-scan" XML tags. Remove or turn off the default annotation configuration there if you intend to specify a custom RequiredAnnotationBeanPostProcessor bean definition.