I must admit I have not made my mind. The small advantage I find in having two annotations
is that it is readable at a glance what the constraint is even just by reading its javadoc
(assuming @Documented). In the second approach, you need to explicitly put it in the
javadoc or have your users access to the source code and parse the @Constraint
What do others think?
On 15 janv. 2013, at 15:14, Gunnar Morling <gunnar(a)hibernate.org> wrote:
2013/1/15 Emmanuel Bernard <emmanuel(a)hibernate.org>
> I can live with that but we must make it crystal clear that in case of
> ambiguity, we raise an exception. Otherwise, someone changing the method
> sig might have some nasty surprises.
And which of the options
@CrossParameterConstraint(validatedBy=MyCrossParameterValidator.class)
@Constraint(validatedBy=MyGenericValidator.class)
public @interface MyConstraint { ... }
vs.
@Constraint(
validatedBy=MyGenericValidator.class,
crossParameterValidatorType=MyCrossParameterValidator.class
)
public @interface MyConstraint { ... }
would you prefer?
Personally I'd lean towards the latter, since there would be exactly one
meta-annotation denoting an annotation as constraint annotation type, with all attributes
for the required configuration.
If following the 2nd approach, we should IMO add a default clause to validatedBy() (set
to the empty array), allowing for the convenient definition of cross-parameter only
constraints. According to [1] this change would be binary-compatible.
But this is no strong preference, I could also live with the two separate annotations.
--Gunnar
[1]
http://wiki.eclipse.org/Evolving_Java-based_APIs_2#Evolving_API_interface...
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev