Spring Data JPA pollutes child contexts with SharedEntityManagerCreator [DATAJPA-1797]

[spring-projects-issues]

Ihor Herasymenko opened DATAJPA-1797 and commented

Reproducible with the latest Spring Data (Neumann-SR4) and Spring Framework 5.2.9.

Not reproducible with the latest Spring Data (Neumann-SR4) and Spring Framework 5.2.5.

Looks like a regression that was introduced by fixing https://github.com/spring-projects/spring-framework/issues/24852

The reproducer is on my Github.

Run all tests by executing gradlew test — one test will fail.

Run gradlew test --tests com.example.Config2Test and then gradlew test --tests com.example.ConfigTest — both tests will succeed

---

Affects: 2.3.4 (Neumann SR4)

Reference URL: https://github.com/iherasymenko/spring-data-jpa-child-context-pollution-reproducer

[spring-projects-issues]

Jens Schauder commented

This seems to be a Spring Framework issue.

Could you please create an issue there: https://github.com/spring-projects/spring-framework/issues

They are already looking into it, but creating an issue there makes sure you get notified when the issue gets fixed

[spring-projects-issues]

Ihor Herasymenko commented

Jens Schauder done!

https://github.com/spring-projects/spring-framework/issues/25926

[spring-projects-issues]

Jens Schauder commented

Thanks. Closing this issue. Progress will be tracked by the Github issue created

[spring-projects-issues]

Ihor Herasymenko commented

Jens Schauder the Spring Core team advised that the issue is in turn in a Spring Data issue.

Please see the explanation provided by Sam Brannen here

[spring-projects-issues]

Oliver Drotbohm commented

To quote the relevant parts from the original ticket, Sam suggested the following:

The Spring Data JPA team should consider fixing this. We can foresee at least two options here: Use a well-defined bean name for the SharedEntityManagerCreator instead of a generated unique name. Instead of directly using BeanDefinitionReaderUtils.registerWithGeneratedName(…) to register the SharedEntityManagerCreator, SD JPA could detect if there is already a SharedEntityManagerCreator bean with an identical bean definition (excluding the bean name) before creating another one with a different generated name.

I guess we could tweak EntityManagerBeanDefinitionRegistrarPostProcessor to defensively check for the presence of SharedEntityManagerCreator instances via BeanFactoryUtils.beanNamesForTypeIncludingAncestors(…) and inspect the BeanDefinition instances for the found names and inspect them for whether they refer to the EntityManagerFactory we're trying to create the creator for.

Happy to pair with you on this one

[adjenks]

@schauder Sorry for my ignorance and sorry to bother you, but how exactly do I specify release 5.2.5 as my dependency so that I can just work around this error for now? I'm actually a bit new to the whole Java ecosystem so I might be doing something wrong.

I added this to my pom file:

    <dependency>
      <groupId>org.springframework</groupId>
      <artifactId>spring-framework-bom</artifactId>
      <version>5.2.5.RELEASE</version>
      <type>pom</type>
    </dependency>

but the tests still fail saying I have duplicate entity managers:

required a single bean, but 2 were found:

• org.springframework.orm.jpa.SharedEntityManagerCreator#0: defined by method 'createSharedEntityManager' in null
• org.springframework.orm.jpa.SharedEntityManagerCreator#1: defined by method 'createSharedEntityManager' in null

[schauder]

There is an article about this https://spring.io/blog/2016/04/13/overriding-dependency-versions-with-spring-boot

Putting the dependency definition into <dependencyManagement> and adding a <scope>import</scope> should do the trick.

[adjenks]

Thank you 🙏 I'll give that a try.

[gregturn]

Duplicate of #2699