Use SyntheticBeanBuildItem to construct HibernateValidatorFactory

[geoand]

• Fixes: NPE at AbstractMethodValidationInterceptor.validateMethodInvocation #47945

[geoand]

It seems like this change has caused more types to be reachable and tripping GraalVM, so it needs more work.

[geoand]

I can continue adding the necessary GraalVM configurations, but I am pretty sure I am missing how things currently work in main WRT native-image for this validator extension, so I'll wait for input from @gsmet on that

[gsmet]

Yeah, so the problem is that with the new code, the ValidatorFactory is initialized at runtime and not at static init.

And things work atm because the VF is initialized at static init.

[geoand]

That definitely makes sense, but the way the Synthetic Bean is created, it should be static-init and not runtime init.

[gsmet]

I added some debug statements and the Function is called when the test is executed, not during the native image build.

[geoand]

@mkouba what is the expectation here for synthetic beans that are staticInit=true? When should the function itself run?

[mkouba]

@mkouba what is the expectation here for synthetic beans that are staticInit=true? When should the function itself run?

The recorder is called during ExecutionTime#STATIC_INIT, i.e. from a generated static initializer...

[geoand]

The recorder yes, but how about the function itself (the one returned by the recorder)?

[mkouba]

The recorder yes, but how about the function itself?

When the relevant bean is created. When exactly? That depends on the scope and the "clients" (e.g. other CDI beans that invoke methods of the bean).

[geoand]

I see, that makes sense. Assuming the bean is @Singleton, is there anyway to guarantee a very eager (i.e. static init) initialization of the bean without writing some kind of dummy code?

[gsmet]

Like an equivalent of startup() but for static init.

[mkouba]

Like an equivalent of startup() but for static init.

Yes, there's BeanConfiguratorBase#startup(int), SyntheticBeanBuildItem.ExtendedBeanConfigurator extends the BeanConfiguratorBase.

[gsmet]

Yes but my understanding of startup() is that it will be run at runtime init?

At least my attempt to use it didn't change at thing.

[gsmet]

@geoand FYI, I pushed an additional commit with some further cleanup that should be squashed once we figure out how to do things properly.

I dropped the additional GraalVM stuff as it's not the way to go.

[geoand]

👍🏽

I'm also trying something to fix native.

[geoand]

Okay, fixed it

[mkouba]

Yes but my understanding of startup() is that it will be run at runtime init?

Ah, yes you're right. I misread your comment. Normal beans can observe the @Initialized(ApplicationScoped.class) lifecycle event but I don't think we have something for synthetic beans. So a workaround would be (a) Arc.container().instance(Foo.class).get() in a recorder method or (b) create an additional class-based bean with an @Initialized(ApplicationScoped.class) observer that consumes Foo...

[geoand]

I pushed a commit that should also be squashed if we agree it's the way to go.

[mkouba]

Note that this only works because HibernateValidatorFactory is @Singleton and not a normal scoped bean with a client proxy.

[geoand]

Yup, I'm aware. If it were ApplicationScoped I would have called toString

[gsmet]

If you end up with a green CI, I think it's good to merge.

[geoand]

CI was green on my fork so I squashed, rebased and my the PR ready for review

[quarkus-bot]

Status for workflow Quarkus CI

This is the status report for running Quarkus CI on commit 86d200b.

✅ The latest workflow run for the pull request has completed successfully.

It should be safe to merge provided you have a look at the other checks in the summary.

You can consult the Develocity build scans.