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@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
