<p>Your arguments make sense to me. +1.</p>
<p>Regards,<br>
Michael</p>
<div class="gmail_quote">On 28 Sep 2012 13:19, "Hardy Ferentschik" <<a href="mailto:hardy@hibernate.org">hardy@hibernate.org</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
<br>
I already commented on Emmanuel's blog post - <a href="http://beanvalidation.org/news/2012/09/12/fine-control-over-method-validation" target="_blank">http://beanvalidation.org/news/2012/09/12/fine-control-over-method-validation</a>, but<br>
want to summarize on the mailing list as well.<br>
<br>
Bottom line is that I am also not convinced that @MethodValidated is needed.<br>
<br>
Let's talk about a the two main use cases this annotation is supposed to solve.<br>
<br>
#1 En- and disabling Method validation.<br>
<br>
Some of the responses on the post saw the use case of @MethodValidated in disabling method validation for classes/methods for performance reasons.<br>
I am not sure, however, whether annotations is the best approach to do this. I think an external configuration (e.g. via xml) is in this case preferable.<br>
The annotation approach is forcing people to recompile and redeploy their code which seems wrong in this use case and might not even be possible.<br>
<br>
Another important point is that this annotation does not work well when used in in hierarchies. To disable a method validation on a method of a subtype you have to<br>
override the method in question to actually be able to place the annotation onto it. This will violate Liskov's substitution principle. This would not be valid:<br>
<br>
public class Foo {<br>
public void placeOrder(@NotNull Order order) {<br>
}<br>
}<br>
<br>
public class Bar extends {<br>
@MethodValidated(validationMode=NONE)<br>
public void placeOrder(Order order) {<br>
}<br>
}<br>
<br>
@MethodValidated would only work on class level.<br>
<br>
#2 Specifying the validation group<br>
<br>
Again, annotations seem to be the wrong vehicle in this case. Really the groups to be validated should be determined<br>
at the top level validateParameters/ReturnValue. To make this fully dynamic the user would need some sort of callback<br>
to dynamically (based on some context information) determine the group to be validated. The callback would give the user<br>
access method is validated on which instance. Based on this the user would return the group to be validated.<br>
The question here is whether every integrator of method validation should provide its own interface/callback or whether<br>
Bean Validation should specify it.<br>
<br>
Bottom line, I am backing up Emmanuel's concerns regarding the usefulness of @MethodValidated. I think the use cases people want<br>
to use @MethodValidated it is not suitable and other options should be explored. Whether we need to specify these right now I am not sure<br>
about.<br>
<br>
Hopefully this revives the discussion :-)<br>
<br>
--Hardy<br>
<br>
<br>
On 12 Jan 2012, at 7:47 PM, Emmanuel Bernard wrote:<br>
<br>
> I am still working on the chapter describing how interceptor tech<br>
> integrates bean validation. We have decided to convert most of the<br>
> recommendations into mandatory rules. In particular around having method<br>
> validation activated by default.<br>
><br>
> Having a annotation to control whether or not a method was validated<br>
> made sense when it was not enabled by default but I wonder if we still<br>
> need it.<br>
><br>
> I have a bunch of questions for you. I tried to keep them short and to<br>
> the point so feel free to answer them one by one.<br>
><br>
> ## What's your use case for disabling method validation?<br>
><br>
> Why would you want to disable method validation on a given method or a<br>
> given class?<br>
><br>
> ## What's your use case for changing the default group?<br>
><br>
> `@MethodValidated(groups=Heavy.class)` let's you change validation from<br>
> the `Default` group to the group of your choice - in this case `Heavy`.<br>
><br>
> Provided that we will offer support for group translation when cascading<br>
> <<a href="http://beanvalidation.org/proposals/BVAL-208/" target="_blank">http://beanvalidation.org/proposals/BVAL-208/</a>><br>
><br>
> public class UserService {<br>
> public void createUser(<br>
> @NotEmpty @Email String email,<br>
> @Valid @ConvertGroup(from=Default.class, to=BasicPostal.class)<br>
> Address address ) {<br>
> ...<br>
> }<br>
> }<br>
><br>
> do we really need the ability do decide which group to use to validate a<br>
> given method? What would be the use case?<br>
><br>
> To me it seems that it could makes sense to validate one group over<br>
> another based on:<br>
><br>
> - some environmental consideration<br>
> say a newbie user has more constraints on how it enters data<br>
> than an advanced user hence different groups<br>
> - the caller<br>
> say a branch of the code wants to apply different rules than<br>
> an other<br>
><br>
> In both case, it does not make sense to define the group via an<br>
> annotation on the method to be validated.<br>
><br>
> This would need to be a rather container specific behavior to let people<br>
> inject the right group for the right context.<br>
><br>
> ## When would you want to only validate parameters or return values?<br>
><br>
> `@MethodValidated.validationMode` let's you validate both method<br>
> parameters as well as return value, or either one of them or none at all.<br>
><br>
> Do you have a use case in mind for such need?<br>
><br>
> ## What inheritance rules make sense for `@MethodValidated`?<br>
><br>
> Assuming we have `@MethodValidated`, we need to define the overriding<br>
> rules.<br>
><br>
> We could decide that `@MethodValided` must be placed on the method to be<br>
> validated (no overriding rule), or we could try and add some or all of<br>
> the following rules:<br>
><br>
> 1. `@MethodValidated` definitions on a method overrides the ones on a<br>
> class<br>
> 2. `@MethodValidated` definition on a subclass overrides the ones on<br>
> superclasses<br>
><br>
> Interfaces make things harder as there would be no magic rule to decide<br>
> which definition has precedence over another in case of conflict.<br>
> We could consider that methods of a class implementing an interface<br>
> inherit the interface `@MethodValidated` definition (unless overridden).<br>
> And in case two interfaces define the same method, overriding the<br>
> `@MethodValidated` definition would be mandatory.<br>
><br>
> I can live with rule 1, I can support rule 2. but I feel that the rules<br>
> related to interfaces make things quite complex and not especially<br>
> readable. Plus I don't see why you would want to add `@MethodValidated`<br>
> on an interface. Not surprising as I don't see why one would do it on a<br>
> class method anyways ;)<br>
><br>
> ## Conclusion<br>
><br>
> I realize that it must look like I am having a `@MethodValidated`<br>
> mid-life crisis but better now than later :D<br>
> _______________________________________________<br>
> beanvalidation-dev mailing list<br>
> <a href="mailto:beanvalidation-dev@lists.jboss.org">beanvalidation-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/beanvalidation-dev</a><br>
<br>
<br>
_______________________________________________<br>
beanvalidation-dev mailing list<br>
<a href="mailto:beanvalidation-dev@lists.jboss.org">beanvalidation-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/beanvalidation-dev</a><br>
</blockquote></div>