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

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

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