Deprecate HibernateJpaSessionFactoryBean (against Hibernate 5.2) [SPR-16016]

[spring-projects-issues]

Naveen Kumar opened SPR-16016 and commented

We're in the process migrating a large spring application to spring-boot and data-jpa. Almost all of the dao's use SessionFactory resource and Hibernate 4's Criteria classes.

Since it's not possible to instantly convert all those dao methods, so we decided to create a SessionFactory bean based on this reference documentation and gradually do jpa migration process.

But we end up with BeanCurrentlyInCreationException (attached the logs). Reproduced the same issue with a sample project and referred the gitlab url for that project. Until now, i have not yet come up with a workaround, so our migration process is blocked on this.

Glad to know if there is any workaround or any other ways to create SessionFactory bean.

Note: Existing application uses thread based session for transaction commits and rollbacks, so it's not feasible to use entityManager.unwrap(Session.class) as it's not thread based at all.

---

Affects: 4.3.11, 5.0 RC4, 5.0 GA

Reference URL: https://gitlab.com/krnaveen14/spring-orm-sessionfactorybean-bug

Attachments:

• direct_sf_unwrap_error.log (2.30 kB)
• error.log (2.31 kB)

Referenced from: commits 66a6fda, bb41cce

Backported to: 4.3.12

[spring-projects-issues]

Juergen Hoeller commented

It looks like you're being hit by Hibernate 5.2's refactoring: Its SessionFactory interface extends EntityManagerFactory now, so there can be a mismatch when trying to adapt a different EntityManagerFactory accordingly.

We'll have to revise HibernateJpaSessionFactoryBean accordingly, or possibly even make HibernateJpaVendorAdapter expose the full SessionFactory interface when running against Hibernate 5.2.

[spring-projects-issues]

Juergen Hoeller commented

For the time being, could you declare an @Bean method that simply does EntityManagerFactory.unwrap(SessionFactory.class) on a passed-in EntityManagerFactory reference, declaring its return type to SessionFactory directly? There is no FactoryBean involved then which might help to avoid such initialization cycles. HibernateJpaSessionFactoryBean is only really meant to be used in XML bean definitions and similar configuration styles.

Since you'll still end up with two beans implementing EntityManagerFactory against Hibernate 5.2 then, it's recommendable to mark one of them as @Primary. That might even be your SessionFactory-returning bean here, serving as both an EntityManagerFactory and a SessionFactory.

[spring-projects-issues]

Naveen Kumar commented

Tried the suggested method of unwrapping SF from EMF. Still same error. Check the direct_sf_unwrap branch and [^direct_sf_unwrap_error.log].

[spring-projects-issues]

Naveen Kumar commented

As spring doesn't allow direct SessionFactory bean definition due to conflicting instance type, came to a workaround of holding SessionFactory inside another custom @Bean as actual SessionFactory provider. Check the workaround branch.

[spring-projects-issues]

Juergen Hoeller commented

Indeed, exposing a provider type is a good workaround since there is no immediate conflict with type-based EntityManagerFactory injection then.

As for an @Bean method with an EntityManagerFactory.unwrap(SessionFactory.class) call, this should nevertheless work when you obtain the original EntityManagerFactory via @Resource("entityManagerFactory") or @Autowired @Qualifier("entityManagerFactory"), narrowing it to its bean name and therefore avoiding the mismatch with the SessionFactory bean that you're currently declaring.

And with respect to HibernateJpaSessionFactoryBean, I'm inclined to deprecate it at this point, adding a warning about Hibernate 5.2 to its javadoc and suggesting a custom unwrap arrangement instead.