HHH-19205 Do not recreate the validator on each BeanValidationEventListener#validate call

[marko-bekhta]

Hey @gavinking , @beikov

Since you've been talking about the validator in the other PR 😄 it got me interested.
The fact that we recreate the validator on each validate call feels a bit redundant, so I've started looking into it. And this PR is where I got so far.

It would be nice if we wouldn't need to have that traversableResolver.addPersisterIfNecessary( persister, sessionFactory ); I've added. But to get rid of it, we need to have access to the built SF (not the one being built that we can get our hands on right now from the integrator). Would it make sense to add some Integrator#postintegrate(Sf sf... ) method that is called at the very end of the SF constructor, then eagerly build the association map?
Or am I missing something here 😄

---

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license
and can be relicensed under the terms of the LGPL v2.1 license in the future at the maintainers' discretion.
For more information on licensing, please check here.

---

https://hibernate.atlassian.net/browse/HHH-19205

[hibernate-github-bot]

Thanks for your pull request!

This pull request appears to follow the contribution rules.

› This message was automatically generated.

[beikov]

LGTM

[gavinking]

Would it make sense to add some Integrator#postintegrate(Sf sf... ) method that is called at the very end of the SF constructor

Sounds reasonable. Or you could register a, um, what's it called? SessionFactoryObserver?

[marko-bekhta]

SessionFactoryObserver seems to work out nicely 😃,
with it, I also removed the concurrent map, as we are now prefilled with all the entities.

[marko-bekhta]

btw ... since it's in the org.hibernate.boot.beanvalidation (public package?), do you want me to mention something in the migration guide or somewhere?

[gavinking]

btw ... since it's in the org.hibernate.boot.beanvalidation (public package?), do you want me to mention something in the migration guide or somewhere?

Nooooooooo, these are definitely implementation details.

The migration guide would be completely useless if it mentioned every single implementation change. Ideally, it should draw people's attention to things they actually need to pay attention to.