Skip to content

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

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
spring-projects-issues opened this issue Sep 13, 2010 · 5 comments
Assignees
Labels
in: data Issues in data modules (jdbc, orm, oxm, tx) type: enhancement A general enhancement
Milestone

Comments

@spring-projects-issues
Copy link
Collaborator

spring-projects-issues commented Sep 13, 2010

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:

1 votes, 2 watchers

@spring-projects-issues
Copy link
Collaborator Author

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
Copy link
Collaborator Author

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
Copy link
Collaborator Author

Juergen Hoeller commented

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

@spring-projects-issues
Copy link
Collaborator Author

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
Copy link
Collaborator Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: data Issues in data modules (jdbc, orm, oxm, tx) type: enhancement A general enhancement
Projects
None yet
Development

No branches or pull requests

2 participants