The problem was not so much to implement the feature (which was
reasonably easy) but to standardize it which was very time consuming.
Every time you add a switch, you divide the usefulness of a tool by
two, so be careful :) It's like the number of mathematic formulas in a
book and its correlation with sales numbers ;)
If you really want a switch, then the default should be to the more
advanced algorithm and not the spec.
On 8 déc. 09, at 01:01, Gunnar Morling wrote:
Hi,
according to the JSR 303 spec type parameters of constraint
validator types
must not resolve to parametrized types (though the spec mentions such
validator types might be allowed in future versions). To my
understanding
that means that validators as the following one are invalid with
respect to
the BV spec:
public class SomeValidator implements
ConstraintValidator<MyAnnotation,
List<Integer>> {
...
}
while the next one is valid:
public class SomeValidator implements
ConstraintValidator<MyAnnotation,
List> {
...
}
Nevertheless also the first validator seems to work fine with HV. So
does HV
here do something more than defined in the spec? If that's the case, I
wonder whether there shouldn't be some kind of switch in HV to be
activated
explicitely in order to allow for this working. That way people
might use
that feature but are made aware that other BV implementations might
reject
such validators. WDYT?
Thanks, Gunnar
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev