BeanPostProcessor that processes jakarta.persistence.PersistenceUnit and jakarta.persistence.PersistenceContext annotations, for injection of the corresponding JPA resources jakarta.persistence.EntityManagerFactory and jakarta.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.

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 Jakarta EE deployment descriptor. By default, those names are considered as resource references (according to the Jakarta 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 Jakarta 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 Jakarta 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 Jakarta 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).