findDefaultEntityManagerFactory should consider EMF bean's primary flag [SPR-7549]

[spring-projects-issues]

Thomas Strecker opened SPR-7549 and commented

I am generally very happay with all the magic Spring provides me. This week, however, I ran into a problem I can't seem to solve, namely having two persistence units and therefore entity manager factories in my application's context.

While everything works perfect when I declare and annotate the EntityManager in all relevant classes with the @PersistenceContext(unitName="XYZ"), I am having a slightly different problem. While one of the persistence units' names is static (b/c I control it) the name of the other is dynamic. This may seem silly but is beyond my control.

So I tried to provide the one EMF with the "primary=true" and the other with the "primary=false" attributes, hoping that the context would inject the primary EMF into those classes where I didn't specify the name of the persistence unit, while the other classes would obtain the EMF specified through the unitName.

Unfortunately, PersistenceAnnotationBeanPostProcessor.findDefaultEntityManagerFactory() does not check for the "primary" attribute of the retrieved beans, therefore complaining that the default entity manager cannot be obtained.

I, therefore, suggest to implement this check in the post processor.

---

Affects: 3.0.4

Issue Links:

• Support for Hibernate ORM 5.2 [SPR-14327] #18899 Support for Hibernate ORM 5.2
• StackOverflowError for advisor search against factory-bean reference to FactoryBean [SPR-14551] #19119 StackOverflowError for advisor search against factory-bean reference to FactoryBean
• Avoid creation of lazy candidates when the primary bean is injected [SPR-14611] #19178 Avoid creation of lazy candidates when the primary bean is injected
• SchedulingConfigurer's ScheduledTaskRegistrar should reliably shut down before TaskScheduler [SPR-15067] #19633 SchedulingConfigurer's ScheduledTaskRegistrar should reliably shut down before TaskScheduler
• Track bean dependencies for calls between @Bean methods within @Configuration classes [SPR-15069] #19635 Track bean dependencies for calls between @Bean methods within @Configuration classes

1 votes, 2 watchers

[spring-projects-issues]

Thomas Strecker commented

I just found the solution, and it already exists in the post processor. I was only ignorant because the name of the property is "defaultPersistenceUnitName". Therefore, I withdraw the request for improvement.

[spring-projects-issues]

Juergen Hoeller commented

Actually, supporting the primary flag for EntityManagerFactory lookup isn't a bad idea at all, in particular since "defaultPersistenceUnitName" requires a custom PersistenceAnnotationBeanPostProcessor definition. We'll consider this for Spring 3.1.

Juergen

[spring-projects-issues]

Juergen Hoeller commented

Closing groups of outdated issues. Please reopen if still relevant.

[spring-projects-issues]

Olivier Sambourg commented

Hi,
Still relevant for me (using Spring 4.0.x), using PersitenceAnnotationBeanPostProcessor requires turning off default annotation processing (which is a shame since we use java config) or naming our bean "org.springframework.context.annotation.internalPersistenceAnnotationProcessor" to override Spring's default one.

[spring-projects-issues]

Juergen Hoeller commented

This actually becomes more important now with Hibernate ORM 5.2 where a SessionFactory reference implements EntityManagerFactory directly, so Hibernate setups with direct SessionFactory exposure can now get mixed up with non-unique EntityManagerFactory matches. A primary flag is an easy way out, or alternatively autowire-candidate=false, both of which work now as of Spring Framework 4.3.3.

Technically, a resolveNamedBean method on AutowireCapableBeanFactory does the general job now, including bean name exposure for dependency registration. PersistenceAnnotationBeanPostProcessor simply delegates to that method now.