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

HibernateTransactionManager (unintentionally) bound to Hibernate 5.2 SharedSessionContractImplementor [SPR-17557] #22089

Closed
spring-issuemaster opened this Issue Dec 2, 2018 · 6 comments

Comments

Projects
None yet
2 participants
@spring-issuemaster
Copy link
Collaborator

spring-issuemaster commented Dec 2, 2018

Taras Tielkes opened SPR-17557 and commented

The compiled version of HibernateTransactionManager seems to contain a reference to SharedSessionContractImplementor (perhaps from the lambda call?).

When running with Hibernate 5.1.x in the classpath, resolution of SharedSessionContractImplementor will fail, triggering a NoClassDefFoundError.

Please take a look at the output of "javap -v" for the compiled version of HibernateTransactionManager in the latest release jar.


Affects: 5.1.3

Issue Links:

  • #21494 Propagate read-only status to Hibernate Session through setDefaultReadOnly
  • #21749 HibernateTransactionManager should lazily acquire JDBC Connection (like HibernateJpaDialect)

Referenced from: commits 0841dc5

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator

spring-issuemaster commented Dec 3, 2018

Zhang Jie commented

spring-orm-5.1.3 uses hibernate-core-5.3.7.Final as dependency, you shouldn't use Hibernate 5.1.x in the classpath.

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator

spring-issuemaster commented Dec 3, 2018

Juergen Hoeller commented

We aim to support any Hibernate ORM 5.x version at runtime, so this is nevertheless a bug... even if we generally recommend Hibernate ORM 5.3.7.

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator

spring-issuemaster commented Dec 3, 2018

Juergen Hoeller commented

This seems to be caused by the sessionImpl::connection method reference, where sessionImpl is a SessionImplementor type but the connection() method is inherited from SharedSessionContractImplementor since Hibernate ORM 5.2 there.

Taras Tielkes, have you seen this as a recent regression in Spring Framework 5.1.x? Does it work with Spring Framework 5.0.x still?

As far as I can see, a simple change to () -> sessionImpl.connection() solves the problem at bytecode level since it compiles to a SessionImplementor reference again. Assuming it still works with Spring Framework 5.0.x (where a similar direct call in in place), that's the change I intend to apply for the 5.1.4 release.

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator

spring-issuemaster commented Dec 3, 2018

Taras Tielkes commented

Juergen Hoeller, for this project we're just now migrating from 4.3.x to 5.1.x, so I don't have any feedback for 5.0.x versions.
However, I'd be happy to check later this evening.

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator

spring-issuemaster commented Dec 3, 2018

Juergen Hoeller commented

No worries, I'll commit the change to master assuming that it solves the problem, so please rather try 5.1.4.BUILD-SNAPSHOT tonight.

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator

spring-issuemaster commented Dec 4, 2018

Taras Tielkes commented

Juergen Hoeller I have tried the SNAPSHOT from last night, and I can confirm that it fixes the issue for us.

This regression was a subtle one - not apparent from reading the source. I'm wondering if it would be possible to catch such cases in an automated way...

As always, thanks for the quick service.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment