My repositories are defined in a reusable service layer and may be imported and used by different applications. Those applications may as well define more than one EntityManagerFactory, but only one will be supplied to <jpa:repositories> definition in the Spring application context to configure my repositories.
The problem is that when I write my custom implementations I may need to get a reference to that EntityManagerFactory, but I couldn't find a way to cleanly do this. In fact, I would need to hard-code in that custom implementation the name of the persistence unit of the EMF I want to receive, in order to get autowiring work correctly. But this is not optimal, of course, because different applications may inject an EMF with a different persistence unit name into my repositories.
The best I could do is to set up a convention: my repository service layer expects that there's an EMF named myConventionalPU available: every application that uses it, must ensure that the EMF injected into Spring Data is also aliased by that conventional name. But it's of course a weak requirement, hard to enforce.
What I would need, in fact, is a way to get information from Spring Data within my custom implementations. Honestly, the fact that the Impl classes are totally unaware of Spring Data, although described as a strength in Spring Data manual, is actually a complication whenever you need to access something that is usually provided by Spring Data itself (the EMF, for instance, or any other standard method of the repository you're customizing. It happens almost always for me.)
I wrote a custom repository for the sole purpose of getting the entity manager. And you are right, when you have multiple persistence units, getting the entity manager from the repository relieves you from specifying which persistence unit you want the EM from as the repository is tied to the entity which is tied to the persistence unit.
We use it for example when working with more advanced features of QueryDsl, like fetch join with deeper level or batch update using criteria. Now that we have entity graph and batch update in JPA 2.1 we may not want that anymore. Anyway, we found QueryDsl to be powerful in that regard.
We extend the implementation of the custom repository from QueryDslJpaRepository and you can get access to the entity manager from the constructor. You just can store that in an instance variable.
It would be nice if the standard repository exposes the entity manager right away
Probably something worth mentioning in there reference documentation, but the basic idea is that you'd get a JpaContext injected into the repository which allows you to obtain the EntityManager per managed domain type
Oliver, I just looked at the implementation of org.springframework.data.jpa.repository.support.DefaultJpaContext.getEntityManagerByManagedType(Class<?>) and I see the case in which an entity class might be managed by more than one entity manager.
But, just for curiosity, why not just providing a getEntityManager() method in JpaRepository to return the entity manager used by the repository you're customizing? In that case, the custom implementation MyEntityRepositoryCustom may simply need to get the MyEntityRepository instance injected and call getEntityManager() on it to get the entity manager in use (without any risk of ambiguity)