Answers inline.
--Gunnar
Am 24.04.2012 10:29 schrieb "Emmanuel Bernard" <ebernard_at_redhat.com>:
>
> Thanks for this detailed email, Ron
>
> I must admit I cannot convince myself whether asking users to add the annotation to validate or asking users to add the annotation to disable is correct. That's why I had not replied yet. At the moment, I tend to agree with Santiago that this should be on by default.
Yes, I think for the JAX-RS case that probably makes sense.
The question is whether that's something which must be defined by the
spec or whether a user might simply enable validation on a global
level using some sort of descriptor file (like validation.xml for BV
or beans.xml for CDI). I think personally I'd prefer the latter option
as it is a bit less “auto-magic“. A way to globally turn off method
validation would probably needed in the case it's implicitly enabled
by default.
I don't know though, whether there is such global descriptor for JAX-XS.
>
> Gunnar, what do think of having method level validations on by default including in CDI. It seems more natural to me (at the moment).
I'm not sure. I think a default enablement is a good choice where the
validation is performed once in typical requests/call stacks (e.g.
when data is entered in the JSF case, or when it's persisted in the
JPA case). When enabling the validation interceptor by default for
CDI, validation would happen for each method invocation of each
managed bean.
I'm not sure whether that's the right thing, I feel users would often
have to configure another behavior, e.g. to validate only invocations
of methods on module/component boundaries etc. The validation of each
method might also have performance implications. All in all I think
explicitly enabling validation is more appropriate for CDI or DI
containers in general.
>
> Here are some data points to help us:
>
> - in JPA and JSF, validation of bean properties is on by default. A user can disable them or change the default group(s) respectively in the persistence.xml file via a property or in the xhtml template via a specific tag
> - the way to override the default group is to use @MethodValidated. This can be applied at the class level, and at the method level.
> - overriding the group at the parameter level will be done in a different mechanism that is being discussed by the EG. But in many ways that's not a common use case.
> - the way to override the validation behavior at the field / property level today in BV is simply by using groups.
> 1. you define the group(s) the constraint reacts to
> 2. you define the group(s) a bean should be validated with
>
> Step 2. is the responsibility of the calling spec. As I mentioned, JPA uses properties and JSF uses tags and EL expressions. I have been thinking about a use case to disable validation in JAX-RS entry points and I realized that statically decide to enable / disable the method-level and bean properties validations is not that useful. I imagine that the group to validate could depend on an external factor like which person is actually calling the service. Eg if that's an Admin, the password should be stronger or if that's a power user, telephone constraints are not applied. I don't know how JAX-RS can receive or access such contextual information. But we should explore that.
Maybe such a facility for such contextual information and validation
group configuration would lso make sense for other integrators, e.g.
JPA?
>
> - Could we imagine that the group(s) to validate for a given entry point be injected by a CDI bean?
> - Should we provide the notion of GroupResolver?
What do you exactly mean by that?
>
> What do you think?
>
> On 19 avr. 2012, at 01:09, Ron Sigal wrote:
>
> > 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.
>