I think there are several levels of granularity that can be addressed by
some kind of annotation:
1. Turning validation on or turning it off. JAX-RS will decide to
either a) turn all validation on by default or b) turn all validation
off by default. Either way, there should be a way of overriding the
default behavior.
2. Once a resource class's validation behavior is determined, it would
be useful to be able to override that behavior at the field, property,
and method level.
3. Once a resource method's validation behavior is determined, it would
be useful to be able to override it at the parameter and return value level.
4. Orthogonal to 1, 2, and 3, it would be useful to specify validation
groups at each level.
As far as it goes, I think @MethodValidated is very useful. My only
concern is that it is meant to apply only to method parameters and
return values, so that fields and properties are ignored. Also, it
determines method validation behavior at the class level, but it doesn't
seem to apply to class level constraints. Why not call it @Validate (or
@Validated or whatever) and extend it to classes, fields, and
properties? The only two necessary changes, I think, would be
1. extend @Target(), and
2. add some more elements (FIELDS, PROPERTIES, and CLASSES) to
ValidationMode.
Then I think it would satisfy all of 1-4 above.
Also, I feel like I highjacked this discussion away from the mailing
lists. I wanted Gunnar and Emanuel to see it, but I probably should
have sent cc'd users_at_jax-rs-spec.java.net Doing that now.
More inline below.
On 4/18/2012 6:31 AM, Marek Potociar wrote:
> Hi Gunar,
>
> I agree with Santiago, some "ignore" annotation for disabling the validation would be more user-friendly IMO.
>
> Also, it's not clear to me what are the proposed mechanisms behind implementing a support for this annotation (in JAX-RS RI). Is the plan still to invoke BV validator and pass it the method signature along with the parameter values? What about return type validation then? Is that supposed to be done in a separate step?
My understanding is that @MethodValidated is semantics free with respect
to BV: JAX-RS could use it anyway you want. In Resteasy, I can imagine
leaving the current code in place, but surrounding it with conditionals
that look at the @MethodValidated (or whatever) annotations. Right now
(as per the spec), field, property, class, and parameter validation is
done, and then, only if they all pass, return type validation is done.
>
> Thanks,
> Marek
>
>
> On Apr 17, 2012, at 11:27 PM, Santiago Pericas-Geertsen wrote:
>
>> Hi Gunnar,
>>
>> Somehow I still think the default mode in JAX-RS should be to validate all constraint annotations. If as a developer I'm going through the trouble of adding all these constraint annotations, why do I need to later turn them on?
You could be using library classes that have unwanted validation.
Probably not the default case ... just saying.
>> Instead, I think I would prefer to have a way to turn them off. Not unlike in JUnit when you go from "@Test" to "@Test @Ignore".
>>
>> In that case we should use @MethodValidated(validationMode=NONE)? It's a bit odd, but may work for us.
>>
>> -- Santiago
>>
>> On Apr 17, 2012, at 5:03 PM, Gunnar Morling wrote:
>>
>>> Hi,
>>>
>>> the current BV 1.1 draft specifies the @MethodValidated annotation for
>>> this [1]. Would that fulfill the needs of JAX-RS?
>>>
>>> --Gunnar
>>>
>>> [1] http://beanvalidation.org/1.1/spec/#validationapi-triggeringmethodvalidation
>>>
>>>
>>> Am 17. April 2012 17:38 schrieb Ron Sigal<rsigal_at_redhat.com>:
>>>> I thought there was a discussion about enabling and disabling validation
>>>> somewhere, but I couldn't find it until now. This is what I (thought I)
>>>> was responding to when I sent the note with subject "Validation and groups"
>>>> to users_at_jax-rs-spec.java.net.
>>>>
>>>> On 02/07/2012 09:22 AM, Santiago Pericas-Geertsen wrote:
>>>>
>>>> Hi Gunnar,
>>>>
>>>> * 7.3: The spec doesn't specify how validation of resource invocations will
>>>> be enabled in general. We haven't finally decided whether we will provide an
>>>> annotation for that purpose in BV, but it's very likely from my perspective
>>>> that we will [3]. So JAX-RS could use that annotation to control whether a
>>>> validation shall happen for a given resource and if so, which groups to
>>>> validate.
>>>>
>>>>
>>>>
>>>> That's interesting. I was thinking that validation for JAX-RS should be
>>>> enabled by default and that we should provide a way to disable it.
>>>>
>>>> --
>>>> Erdös number 4.