[bv-dev] Representation of cross-parameter constraints

[Gunnar Morling]

Hi all,

Could you give us your feedback on BVAL-370 [1]?

This is about how cross-parameter constraints should be represented in the
metadata and other APIs. Currently, cross-parameter constraints are
represented directly on the ExecutableDescriptor, contrary to parameter and
return value constraints, which are reachable via
ExecutableDescriptor#getParameterDescriptors() and
getReturnValueDescriptor().

A similar question arises when building property paths for cross-parameter
constraints. This is currently still undefined in the spec; The RI adds one
node representing the hosting executable, while another node is added for
parameter and return value violations.

The same with XML descriptors, where <cross-parameter-constraint>
element(s) are directly added to the method/constructor element, as opposed
to parameter/return value constraints which are added to the
<parameter>/<return-value> sub-elements.

The question is, whether we should add such an intermediary descriptor/node
also for cross-parameter constraints, e.g.
ExecutableDescriptor#getCrossParameterDescriptor(). This would make the API
more regular (all executable descriptors/constraints are retrieved by
stepping one level down into the model), possibly helping to avoid
confusions. By introducing an element CROSS_PARAMETER, also cross-parameter
path nodes can be recognized very explicitly (today this is indicated by
Kind.METHOD/CONSTRUCTOR on the leaf node).

On the other hand this is technically not strictly required (all
information can be retrieved unambiguously from the current API). Also
would be the question what to return from e.g.
ExecutableDescriptor#getConstraints() (which currently is re-defined to
return cross-param constraints only). One possibility would be to consider
all executable constraints and extend the constraint finder API to allow
filtering by ElementDescriptor.Kind.

Any thoughts?

Thanks,

--Gunnar

[1] https://hibernate.onjira.com/browse/BVAL-370
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20130211/68c0de7f/attachment.html