It's not a payload thout, is it? More of a shared/reusable/cached context?

Also I wouldn't include ConstraintValidator in the name considering we're in HibernateConstraintValidatorInitializationContext already.

or

Alternatively if you really intend a cache here, you could make this closer to what @Sanne added to Hibernate ORM recently: https://github.com/hibernate/hibernate-orm/blob/bfa7102e228887a7f9e45211a7b051e5b1791215/hibernate-core/src/main/java/org/hibernate/internal/util/cache/InternalCacheFactory.java#L14 . Which would allow integrators to plug a custom cache provider, like Caffeine, which is known to have very good performance.

That being said if the cache is only there for bootstrap, and gets cleared/deleted once bootstrap is finished, using Caffeine is probably overkill...

yeah ... naming is hard 😔 🙂
Yes, it's closer to shared context. The other thought that I had about this: if we were always running the validator in the CDI context and with the predefined scope (i.e. all metadata is built at boot and not dynamically at runtime), I'd think of PatternConstraintInitializer as a bean that we inject into the PatternValidator, and the scope of such beans would be the init phase of the validator factory... but we aren't always running in CDI 🙈

I thought ... that shared service might be a good fit for the name 🙂 🫣

I would say that a service is generally stateless, but YMMV :)

If cache really rubs you the wrong way, maybe sharedData?

By the way, why getConstraintValidatorInitialization*? This is a method in initializationContext, so get* would be enough, no?

If cache really rubs you the wrong way, maybe sharedData?

ha 🙂 yeah ... I don't know, cache somehow doesn't feel right 😔... since you could pass around anything, not just a map of patterns ... so maybe if it was initContext.getCache().get(smth) then cache seems like a nice fit. But when it's initContext.getSomethingFromTheInitCache(smth) ... yeah I don't know 😔

and since clearing the cache for the pattern "shared service" explicitly felt more like a "hack" I've added this observer to react to HV factory lifecycle events and used it to clear the cache instead...

Or... hear me out...

Map<Class<?>, Object> sharedData = new HashMap<>();
<T> T getSharedData(Class<T> clazz) {
 return sharedData.computeIfAbsent(clazz, ignored -> clazz.getConstructor().newInstance());
}

... and then everything gets garbage-collected when the context does.

Or do you really need to pass something that gets created before all this, or to close some files after initialization?

This seems very complicated to me, I must be missing a requirement.

Hmm, I'll have to see how it is done for the predefined scope... I don't remember if the init context there is "short lived" or if it stays available for the whole lifetime of the factory... it should stay available for the regular case, as for it, the metadata is built lazily on the first validation attempt...

... I think?

Or... hear me out...

Map<Class<?>, Object> sharedData = new HashMap<>();
<T> T getSharedData(Class<T> clazz) {
 return sharedData.computeIfAbsent(clazz, ignored -> clazz.getConstructor().newInstance());
}

... and then everything gets garbage-collected when the context does.

Or do you really need to pass something that gets created before all this, or to close some files after initialization?

This seems very complicated to me, I must be missing a requirement.