[bv-dev] Proposal for @CanValidate instead of @CrossParameterConstraint (Was Re: Specifying no validator for cross-param constraint)

2013/2/8 Emmanuel Bernard <emmanuel(a)hibernate.org&gt; > Remember that I some point we discussed the ability to associate a > constraint and its implementation via a registry or service locator > mechanism. > https://hibernate.onjira.com/browse/BVAL-252 > > In that environment, the idea of a mandatory validatedBy element on > @CrossParameterConstraint is not very appealing. We could: > > - make it an array but it's really the 0 or 1 semantic we are looking > for > - accept any class so that we can use void.class as default value > - use the @Validates approach > @Validates seems the best from these to me, as the other options change the semantics/type-safety of the API. I'm also starting to like the idea, that there is one way to define a constraint annotation type (annotate it with @Constraint), while everything related to the supported types is handled in the validator implementation. > > Emmanuel > > On Fri 2013-02-08 16:10, Hardy Ferentschik 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(a)hibernate.org&gt; 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(a)lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev > > > > > > _______________________________________________ > > beanvalidation-dev mailing list > > beanvalidation-dev(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev > _______________________________________________ > beanvalidation-dev mailing list > beanvalidation-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev >

_______________________________________________ beanvalidation-dev mailing list beanvalidation-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/beanvalidation-dev