Wrapping of a class that defines the constraint validation rules

[marko-bekhta]

This PR is to address

IIRC, Gunnar had a good idea about requiring a wrapping here. It goes with the idea of wrapping the mapping name or the class.

from the https://github.com/hibernate/hibernate-validator/pull/989

The wrapping class is called HibernateConstrainedType. Prior to actually wrapping the class as a "thing" that defines validation rules a few more changes were applied. I tried to make all of them as small as I could.

In this PR you would see the similar change for cascading metadata and how it is retrieved. And to answer the question from the other PR - I was thinking about the case when we would have something like

class A {
    @ValidPropertyHolder("someMapping")
    private PropHolder holder;
}

where the properties of a regular bean are property holders and I would like us not to "special case" them, but rather treat them as a regular properties marked for cascading.

If the changes in general are OK, we can also try to reduce the amount of created HibernateConstrainedTypes especially the ones in constraint location classes. Didn't want to go for it right away as it looks like it might require some more change, and the PR is getting big already 😃

I'm also still not 100% convinced that we should keep the metadata in ValueContext...

Any feedback is welcomed, especially on the naming of classes 😄

[marko-bekhta]

Hi @gunnarmorling, thanks for the questions :)

Yes, the idea is to use this same type for the property holders (or free form validation) as well. And in that case I was thinking that we would return the class of an object that really holds the data - map, json etc. Now that you've asked it - I looked at the final version of the code and I think we can move this method to JavaBeanConstrainedType which is an impl of this interface. Right now it is used to log some messages (we can just update the methods in LOG to use this new interface instead and add nice toString), and inside javabean specific code like in annotation based provider (and in this case we don't want to pass anything else but java beans to it). It was useful initially as there were a lot of places that would fail to compile 😃. So I'll probably apply the change that I've just described above and then we can continue looking at this PR.

[gunnarmorling]

I looked at the final version of the code and I think we can move this method to JavaBeanConstrainedType which is an impl of this interface.

Yes, that'd seem reasonable.