Skip to content

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

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 Dec 2, 2018 · 6 comments
Assignees
Labels
in: data Issues in data modules (jdbc, orm, oxm, tx) type: regression A bug that is also a regression
Milestone

Comments

@spring-projects-issues
Copy link
Collaborator

spring-projects-issues 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:

Referenced from: commits 0841dc5

@spring-projects-issues
Copy link
Collaborator Author

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

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

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

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

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

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
Labels
in: data Issues in data modules (jdbc, orm, oxm, tx) type: regression A bug that is also a regression
Projects
None yet
Development

No branches or pull requests

2 participants