4.x: Tests fail when upgrading to Hibernate 6.6.23.Final #10441

[jbescos]

Description

Resolves #10441

Hibernate 6.6 cannot attach a removed entity:
https://docs.jboss.org/hibernate/orm/6.6/migration-guide/migration-guide.html#merge-versioned-deleted

[ljnelson]

I want to be careful here; I think it should be possible to merge a detached entity according to the spec.

Specifically, the spec says:

If X is a detached entity, the state of X is copied onto a pre-existing managed entity instance X' of the same identity or a new managed copy X' of X is created.

Then, recently, Hibernate says:

Previously, merging a detached entity resulted in a SQL insert whenever there was no matching row in the database (for example, if the object had been deleted in another transaction). This behavior was unexpected and violated the rules of optimistic locking.

Indeed, merging a detached entity X when there is no "pre-existing managed entity instance X'" should result in an INSERT when everything is said and done since that's how the persistence context works in all other cases. I'm not sure why Hibernate asserts that this is unexpected.

[jbescos]

I want to be careful here; I think it should be possible to merge a detached entity according to the spec.

Specifically, the spec says:

If X is a detached entity, the state of X is copied onto a pre-existing managed entity instance X' of the same identity or a new managed copy X' of X is created.

Then, recently, Hibernate says:

Previously, merging a detached entity resulted in a SQL insert whenever there was no matching row in the database (for example, if the object had been deleted in another transaction). This behavior was unexpected and violated the rules of optimistic locking.

Indeed, merging a detached entity X when there is no "pre-existing managed entity instance X'" should result in an INSERT when everything is said and done since that's how the persistence context works in all other cases. I'm not sure why Hibernate asserts that this is unexpected.

Thanks @ljnelson , does it make sense that you open them an issue to discuss this?.

[jbescos]

Native image fails consistently:
tests/native-image-mp-2-windows

Caused by: org.apache.maven.plugin.MojoExecutionException: Execution of C:\hostedtoolcache\windows\graalvm-jdk-21.0.3_windows-x64_bin\21.0.3\x64\graalvm-jdk-21.0.3+7.1\bin\native-image.cmd @target\tmp\native-image-5266420025302078153.args io.helidon.tests.integration.packaging.mp2.Mp2Main returned non-zero result
    at org.graalvm.buildtools.maven.AbstractNativeImageMojo.buildImage (AbstractNativeImageMojo.java:429)
    at org.graalvm.buildtools.maven.NativeCompileNoForkMojo.execute (NativeCompileNoForkMojo.java:104)

[jbescos]

It is passing now

[Sanne]

@jbescos such metadata should be unnecessary if you use the Hibernate provided GraalVM module?
-https://github.com/hibernate/hibernate-orm/blame/main/hibernate-graalvm/src/main/java/org/hibernate/graalvm/internal/StaticClassLists.java#L68

I created that module to simplify such integrations by other frameworks, please let us know if it's not useful.

[jbescos]

In this file we tell GraalVM what classes should be available for reflection at runtime. I added that because GraalVM told me to do so.

We don't have org.hibernate.orm:hibernate-graalvm as dependency, but I have added it and the test fails, with and without this configuration. It compiles well, but in runtime I am having some ClassNotFoundExceptions.

[Sanne]

In this file we tell GraalVM what classes should be available for reflection at runtime. I added that because GraalVM told me to do so.

I understand, but it makes more sense to have the rules which are specific to a library to be maintained by the library - otherwise you'll need to make changes for each new Hibernate release.
So for that reason I had created the hibernate-graalvm module.

We don't have org.hibernate.orm:hibernate-graalvm as dependency, but I have added it and the test fails, with and without this configuration.

Such features need to be activated

[Sanne]

My concern would be that this is going to fail at runtime. Just hiding / postponing problems.

[jbescos]

We use static enhancement, so bytebuddy related things should not be executed. This args allows me to replace the static fields that are triggering reflection.

[Sanne]

I understand - but the compiler is usually right, it's running a formal proof. So if it's including it, this would suggest that there are some corner cases in which this code is necessary.

[jbescos]

Adding --trace-class-initialization only shows the stack traces I printed here. It starts with ByteBuddyEnhancementContext and ByteBuddyProxyHelper. We cannot know more about why are that static fields loaded.

We already have a lot of GraalVM configuration related to Hibernate here and some other methods substitutions here. I was not part of this, but it seems this integration was not easy.