Only the ap. On 10 déc. 2009, at 13:06, Gunnar Morling wrote:
> 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 <emman...@hibernate.org> > 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 <emman...@hibernate.org> >> 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 <emman...@hibernate.org> >>> 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
