[bv-dev] Representation of cross-parameter constraints

[Emmanuel Bernard]

We went for this solution. We now have a CrossParameterDescriptor
available from ExecutableDescriptor. By symmetry we also have added an
explicit node representing cross parameter. It does nto look too bad, we
managed to find decent values for most if not all methods.

Emmanuel

On Mon 2013-02-11  9:34, Matt Benson wrote:
> I do find the symmetry of the CrossParameterDescriptor attractive.  As for
> the ExecutableDescriptor#getConstraints() question, I would agree that your
> suggestion to extend the ConstraintFinder API is probably more sensible
> than any other approach I can think of.
> 
> $0.02,
> Matt
> 
> 
> On Mon, Feb 11, 2013 at 8:10 AM, Gunnar Morling <gunnar at hibernate.org>wrote:
> 
> > 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
> >
> > _______________________________________________
> > beanvalidation-dev mailing list
> > beanvalidation-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> >

> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev