[bv-dev] Why do we need @MethodValidated anyways?

[Emmanuel Bernard]

I am still working on the chapter describing how interceptor tech
integrates bean validation. We have decided to convert most of the
recommendations into mandatory rules. In particular around having method
validation activated by default.

Having a annotation to control whether or not a method was validated
made sense when it was not enabled by default but I wonder if we still 
need it.

I have a bunch of questions for you. I tried to keep them short and to
the point so feel free to answer them one by one.

## What's your use case for disabling method validation?

Why would you want to disable method validation on a given method or a
given class?

## What's your use case for changing the default group?

`@MethodValidated(groups=Heavy.class)` let's you change validation from
the `Default` group to the group of your choice - in this case `Heavy`.

Provided that we will offer support for group translation when cascading
<http://beanvalidation.org/proposals/BVAL-208/>

    public class UserService {
        public void createUser(
            @NotEmpty @Email String email,
            @Valid @ConvertGroup(from=Default.class, to=BasicPostal.class)
            Address address ) {
            ...
        }
    }

do we really need the ability do decide which group to use to validate a
given method? What would be the use case?

To me it seems that it could makes sense to validate one group over
another based on:

- some environmental consideration
  say a newbie user has more constraints on how it enters data
  than an advanced user hence different groups
- the caller
  say a branch of the code wants to apply different rules than
  an other

In both case, it does not make sense to define the group via an
annotation on the method to be validated.

This would need to be a rather container specific behavior to let people
inject the right group for the right context.

## When would you want to only validate parameters or return values?

`@MethodValidated.validationMode` let's you validate both method
parameters as well as return value, or either one of them or none at all.

Do you have a use case in mind for such need?

## What inheritance rules make sense for `@MethodValidated`?

Assuming we have `@MethodValidated`, we need to define the overriding
rules.

We could decide that `@MethodValided` must be placed on the method to be
validated (no overriding rule), or we could try and add some or all of
the following rules:

1. `@MethodValidated` definitions on a method overrides the ones on a
  class
2. `@MethodValidated` definition on a subclass overrides the ones on
  superclasses

Interfaces make things harder as there would be no magic rule to decide
which definition has precedence over another in case of conflict.
We could consider that methods of a class implementing an interface
inherit the interface `@MethodValidated` definition (unless overridden).
And in case two interfaces define the same method, overriding the
`@MethodValidated` definition would be mandatory.

I can live with rule 1, I can support rule 2. but I feel that the rules
related to interfaces make things quite complex and not especially
readable. Plus I don't see why you would want to add `@MethodValidated`
on an interface. Not surprising as I don't see why one would do it on a
class method anyways ;)

## Conclusion

I realize that it must look like I am having a `@MethodValidated`
mid-life crisis but better now than later :D