Sounds like a very reasonable plan. It could definitely unity a fair bit of code. +1

This follows up on changes begun with HV-638.

The idea is to not only unify parameter and return value validation but also method and normal bean validation. For that purpose, the validation routine should work on facet interfaces which describe one aspect of a validated element (e.g. the ability to return the constraints of an element or get cascadad sub-elements) but abstract from the type of the validated element (e.g. a bean, the arguments of a method or its return value).

So far we have two facet interfaces, Validatable and Cascadable which allow for a unified handling of cascaded validation. Likely we need another one, e.g. to be named Describable, which returns the descriptor representation of an element. The facet interfaces are implemented by the elements of the aggregated model (BeanMetaData, ExecutableMetaData etc.).

The model could look like this in the end:

• BeanMetaData: implements Validatable and Describable, provides access to ExecutableMetaData

• ExecutableMetaData: implements Describable, provides access to ParameterListMetaData and ReturnValueMetaData

• PropertyMetaData: implements Describable and Cascadable

• ParameterMetaData: implements Describable and Cascadable

• ParameterListMetaData: implements Validatable and Describable

• ReturnValueMetaData: implements Validatable and Describable

The Describable facet could be used for creating property paths for constraint violations. We would gather the Describable s for the traversed elements in a stack, when doing cascaded validations. In case of a constraint violation we'd retrieve the descriptor representations of the collected elements and create a property path from them.

Sure. I assume you are taking this one on. We can see when you have something which is worth including. The issue itself, however, not delay releases, but we just move it along.

I think it's still an issue, there are definitely some redundancies in ValidatorImpl. We might try to address this in HV 4.3. I think the code base will generally benefit from it, also if the public API will finally change in HV 5. We still might defer it if we think it's taking too long. WDYT?

Is this still an issue and should this be addressed now or deferred to HV5?