[bv-dev] Path validation

[Matt Benson]

In working with bean validation I have found it useful to program to
the Path interface and have discussed with other Apache BVal
developers in the past the idea of adding #validateProperty() and
#validateValue signatures that take Path arguments in place of the
existing Strings.  It would probably be easiest to add this to a new
interface, e.g.:

public interface javax.validation.PathValidator extends
javax.validation.Validator {
  <T> java.util.Set<javax.validation.ConstraintViolation<T>>
validateProperty(T object, javax.validation.Path propertyName,
java.lang.Class<?>... groups);

  <T> java.util.Set<javax.validation.ConstraintViolation<T>>
validateValue(java.lang.Class<T> beanType, javax.validation.Path
propertyName, java.lang.Object value, java.lang.Class<?>... groups);
}

Things of this type are extremely easy to do given the specification
of Validator#unwrap().  This also involves the related idea, which I
would also like to discuss, of whether Bean Validation might specify
certain interfaces as being optional.  At the very least, regardless
of whether a given interface is considered mandatory for a complying
implementation to support, decoupling allows the implementor some
freedom in deciding how to support these APIs, and   maintains binary
compatibility among versions as far as possible by leaving existing
interfaces intact (which may indeed have been an intended effect of
the #unwrap() APIs).  I'd be glad to hear from anyone who has any
thoughts on these matters!

Matt