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

Hi, I definitely see the usefulness of the feature. It's just that constraint implementors should see clearly, when they are leaving BV spec territory. How about having the HV annotation processor issue a warning at such advanced validator type definitions? Gunnar 2009/12/8 Emmanuel Bernard <emmanuel(a)hibernate.org&gt; 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

Allowing validators for parametrized types is definitely a good thing, but right now it is not part of the spec. Let me compare this to JPA and Hibernate as provider. There are many great features that Hibernate adds to the spec. But when using them you are aware of the fact that your code now depends one a concrete provider, for instance by importing stuff from org.hibernate.*. That's not the case with the advanced validator types. They are just working fine on HV, but there is no pointer, that such a validator might not run on another BV implementation. Therefore I think one should provide constraint authors with a facility for checking whether their constraints are spec-compliant or not. Then they can decide whether to stick strictly to the spec or use the more advanced style, but there are no surprises when using another BV implementation. Thanks for pointing to that lib, I'll have a look at it. 2009/12/9 Emmanuel Bernard <emmanuel(a)hibernate.org&gt; That would encourage people to use weaker generics or even worse, raw types. BTW, check out http://code.google.com/p/reflext/ by Julien Viet It might help in the quest to resolve types simply with the mirror API. On 8 déc. 09, at 22:29, Gunnar Morling wrote: > Hi, > > I definitely see the usefulness of the feature. It's just that constraint implementors should see clearly, when they are leaving BV spec territory. > > How about having the HV annotation processor issue a warning at such advanced validator type definitions? > > Gunnar > > > > 2009/12/8 Emmanuel Bernard <emmanuel(a)hibernate.org&gt; > 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 > >

Sounds good to me. I'll see what kind of severities are possible within the AP. You mean we should have this only within the AP or in the runtime, too? 2009/12/10 Emmanuel Bernard <emmanuel(a)hibernate.org&gt; I am fully aware of that, though in this case the intend of the spec is to support it, it's just that we could not spec the feature in time. The ap should not fail if someone is using a provider specific feature (which it will with your approach) or that would be against the philosophy of extensibility the spec and the EG prone. Let's add a strict-compliance flag but leave it disabled by default. Alternatively, just flag as info when an extended mode is found. On 10 déc. 2009, at 08:30, Gunnar Morling wrote: > Allowing validators for parametrized types is definitely a good thing, but right now it is not part of the spec. > > Let me compare this to JPA and Hibernate as provider. There are many great features that Hibernate adds to the spec. But when using them you are aware of the fact that your code now depends one a concrete provider, for instance by importing stuff from org.hibernate.*. > > That's not the case with the advanced validator types. They are just working fine on HV, but there is no pointer, that such a validator might not run on another BV implementation. > > Therefore I think one should provide constraint authors with a facility for checking whether their constraints are spec-compliant or not. Then they can decide whether to stick strictly to the spec or use the more advanced style, but there are no surprises when using another BV implementation. > > Thanks for pointing to that lib, I'll have a look at it. > > > > 2009/12/9 Emmanuel Bernard <emmanuel(a)hibernate.org&gt; > That would encourage people to use weaker generics or even worse, raw types. > BTW, check out http://code.google.com/p/reflext/ by Julien Viet > It might help in the quest to resolve types simply with the mirror API. > > > On 8 déc. 09, at 22:29, Gunnar Morling wrote: > >> Hi, >> >> I definitely see the usefulness of the feature. It's just that constraint implementors should see clearly, when they are leaving BV spec territory. >> >> How about having the HV annotation processor issue a warning at such advanced validator type definitions? >> >> Gunnar >> >> >> >> 2009/12/8 Emmanuel Bernard <emmanuel(a)hibernate.org&gt; >> 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 >> >> > >