Regression with build-tools.native 1.0.0 & Spring Boot & Hibernate Validator

[goafabric]

Description

There is a issue with building native images with

• latest version 1.0.0 for gradle
• in combination with Spring Boot 4.0.5
• and Hibernate Validator present on the classpath

See error below.
Everything is fine with version 0.11.5

** Related Issues **
This is seemingly not the first time it happened:
oracle/graal#5626
oracle/graal#8474

** Fix **
In Spring boot it can be fixed by adding, so i guess reachability metadata is missing

`
hints.reflection().registerType(TypeReference.of("org.hibernate.validator.internal.util.logging.Log_$logger"),
builder -> builder.withMembers(MemberCategory.INVOKE_DECLARED_CONSTRUCTORS));

hints.reflection().registerType(TypeReference.of("org.hibernate.validator.internal.util.logging.Messages_$bundle"),
builder -> builder.withMembers(MemberCategory.INVOKE_DECLARED_METHODS).withField("INSTANCE"));
`

** 1st Error **

`
Caused by: java.lang.IllegalArgumentException: Invalid logger interface org.hibernate.validator.internal.util.logging.Log (implementation not found)

at org.jboss.logging.Logger.doGetMessageLogger(Logger.java:2632)

at org.jboss.logging.Logger.getMessageLogger(Logger.java:2536)

at org.jboss.logging.Logger.getMessageLogger(Logger.java:2521)

at org.hibernate.validator.internal.util.logging.LoggerFactory.make(LoggerFactory.java:21)

`

** 2nd Error **

Caused by: java.lang.IllegalArgumentException: Invalid bundle interface org.hibernate.validator.internal.util.logging.Messages (implementation not found) at org.jboss.logging.Messages.doGetBundle(Messages.java:153) at org.jboss.logging.Messages.getBundle(Messages.java:111) at org.jboss.logging.Messages.getBundle(Messages.java:97) at org.hibernate.validator.internal.util.logging.Messages.<clinit>(Messages.java:20) ... 45 more

[jormundur00]

Hello goafabric, thanks for reporting this issue!

The 1.0.0 version of Native Build Tools uses the 1.0-M1 version of the reachability metadata repository, which uses the new reachability-metadata.json metadata format. With this migration, we expect these kinds of regressions to happen.

Could you provide me with a reproducer to the issues above, so I can take a look at where we're missing metadata (if that is indeed the issue)?

[goafabric]

I can .. but the reproducers are rather complex ...
And this also only seems to happen with springs paketo build, triggerd by "bootBuildImage".
Not with local graalvm

simple reproducer, only for the first error
callee-service.zip

more complex reproducer, for both errors.
person-service.zip

[goafabric]

and thx 4 getting back so fast ... but one question, why does a final version 1.0.0 include an M1 dependency ?
And btw, the error is pretty much identical as to the one from 2022:
oracle/graal#5626

[jormundur00]

and thx 4 getting back so fast ... but one question, why does a final version 1.0.0 include an M1 dependency ? And btw, the error is pretty much identical as to the one from 2022: oracle/graal#5626

1.0.0 of NBT was originally set to be 1.0-M1 as well, but due to company policy we had to rename it to 1.0.0. The metadata format migration is a big change where regressions are expected, so it will probably take some time and help from the community (with issues like these) to get it fully stable :)

[goafabric]

ok .. thx 4 the explanation and getting back so fast

[jormundur00]

I can .. but the reproducers are rather complex ... And this also only seems to happen with springs paketo build, triggerd by "bootBuildImage". Not with local graalvm

simple reproducer, only for the first error callee-service.zip

more complex reproducer, for both errors. person-service.zip

Could you provide a more comprehensive reproducer with reproduction steps? I'm not familiar with the paketo build and am unable to reproduce locally.

[goafabric]

@jormundur00
Yeah i expected this ... so it only seems to happen with the Paketo Builder, maybe because of the changes you mentioned above.

"The 1.0.0 version of Native Build Tools uses the 1.0-M1 version of the reachability metadata repository, which uses the new reachability-metadata.json"

To build it you need gradle + docker and then execute the task "bootBuildImage" .. i will build the image inside docker.

But thats all i can provide for now sorry .. already went the extra mile for verification which hints have been missing.

So maybe someone from the Spring Team could help like @philwebb who also participated in oracle/graal#8474

If everything fails, feel free to close the bug, .. so I would expect that in one way or the other the bug will be discovered by Spring Team itself

[goafabric]

Taking a look at the final native image, with the fixed I applied, it at least boostraps now
But more errors concerning "reachability metadata" are popping up.
So i guess together with your verfication that is workig with local graalvm, there is definitely something that needs to be done on Spring Boots end.

I reverted everything back to old 0.11.5 for now
=> Will the 0.11.x version still receive updates and fixes, or only 1.x ?

[jormundur00]

Taking a look at the final native image, with the fixed I applied, it at least boostraps now But more errors concerning "reachability metadata" are popping up. So i guess together with your verfication that is workig with local graalvm, there is definitely something that needs to be done on Spring Boots end.

I reverted everything back to old 0.11.5 for now => Will the 0.11.x version still receive updates and fixes, or only 1.x ?

I believe that going forward only 1.x will receive updates, as we anyhow want the community to switch to the new metadata format.

Regarding this issue: I will speak further with the Spring team on a meet we have today.

[goafabric]

Taking a look at the final native image, with the fixed I applied, it at least boostraps now But more errors concerning "reachability metadata" are popping up. So i guess together with your verfication that is workig with local graalvm, there is definitely something that needs to be done on Spring Boots end.
I reverted everything back to old 0.11.5 for now => Will the 0.11.x version still receive updates and fixes, or only 1.x ?

I believe that going forward only 1.x will receive updates, as we anyhow want the community to switch to the new metadata format.

Regarding this issue: I will speak further with the Spring team on a meet we have today.

thank you

[jormundur00]

We spoke a bit further on this topic on our meet, and got a few points:

1. As I'm having trouble reproducing, could you run your failing builds with --exact-reachability-metadata and -XX:MissingRegistrationReportingMode=Warn flags and post the resulting stacktraces here, as that should point any missing metadata registrations (which I suspect are the issue here)? You can take a look at the troubleshooting guide if anything is unclear.
2. The Spring team will soon update their tests to also use NBT 1.0.0, so I suspect we will soon have an easier time reproducing and fixing these issues.

[goafabric]

unfortunately i cannot provide this, as all of this is handled internally by springs paketo builder
and appending these as extra args, just makes the build crash immediately

its good that you are in contact with the spring people, I would now expect them to take a look and provide the information

[jormundur00]

Alright, I'll leave this issue open for now. I expect that we will get an easier way to reproduce this soon, when Spring starts using NBT 1.0.0 internally, but for the time being we can use this issue to keep track of the existing problem.