[bv-dev] Specifying no validator for cross-param constraint
Matt Benson
mbenson at apache.org
Fri Feb 8 11:59:13 EST 2013
Option #3 is fine, along with narrowing
@CrossParameterConstraint#validatedBy() to <?, Object[]>.
For the sake of discussion, I was a bit intrigued by option #2, as:
public interface ConstraintValidator<A, T> {
public final class Noop implements ConstraintValidator<Annotation,
Object> {
//appropriate impl
}
}
Then this class could be used anywhere. Alternatively, it could be
non-instantiable and be explicitly ignored by implementations. But would
Annotation even be the right parameter for Noop.<A>? Would existing Bean
Validation implementations be able to resolve this as validating a given
constraint type? Note that, if these issues could be satisfactorily
resolved, it would probably be appropriate to narrow
@CrossParameterContraint#validatedBy() to <?, ? super Object[]>.
Matt
On Fri, Feb 8, 2013 at 9:10 AM, Hardy Ferentschik <hardy at hibernate.org>wrote:
> Hi,
>
> Is this not where 'include-existing-validators="true"' in the XML config
> comes into play as well?
> So it is still possible to configure via XML with the default constraint
> implementation in- or excluded.
> I don't see a need for a provided NoOpValidator provided by the API. If
> you don't want to provide a
> actual implementation you can create your own dummy.
>
> I still against option #1. So I guess I reasoned myself into #3
>
> --Hardy
>
>
>
>
> On 8 Jan 2013, at 2:56 PM, Gunnar Morling <gunnar at hibernate.org> wrote:
>
> > All,
> >
> > I just noticed that it's currently not possible to specify *no*
> validator type for cross-parameter constraints:
> >
> > @CrossParameterConstraint(validatedBy=...)
> > MyCrossParamConstraint{ ... }
> >
> > Not specifying a validator might be relevant for people who want to hide
> their validator implementations and e.g. configure them via XML. Null is
> not allowed as annotation member value, and it's also not possible to
> specify ConstraintValidator.class as dummy value (doesn't compile).
> >
> > Note that the problem doesn't exist with @Constraint where validatedBy()
> expects an array of class objects, allowing empty arrays. The following
> solutions come to my mind:
> >
> > #1 Get rid of @CrossParameterConstraint, use @Validates on validator
> implementations, as discussed as alternative before
> >
> > #2 Offer a dummy NoOpValidator in the API, obviously rather inelegant
> >
> > #3 Ignore the problem, maybe the use case is really uncommon? If
> required, recommend people to use their own dummy validator and override it
> via XML
> >
> > On a related note, if sticking to @CrossParameterConstraint, we may
> consider to narrow the type of supported validators:
> >
> > public @interface CrossParameterConstraint {
> > Class<? extends ConstraintValidator<?, Object[]>> validatedBy();
> > }
> >
> > I.e., only validators for Object[] would be allowed (currently that's
> demanded by the JavaDocs only).
> >
> > Any thoughts?
> >
> > --Gunnar
> >
> > _______________________________________________
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20130208/3e27c0fb/attachment.html
More information about the beanvalidation-dev
mailing list