Hi Gunnar,
What we really need in JAX-RS is an annotation that can be used to (temporarily) disable validation at any location: resource classes, fields, properties and methods. Something like @IgnoreValidation that can be used as follows:
@Path("/")
@NonEmptyNames @IgnoreValidation
class MyResourceClass {
@NotNull @FormParam("firstName") @IgnoreValidation
private String firstName;
@NotNull @FormParam("lastName")
private String lastName;
private String email;
@FormParam("email")
public void setEmail(String email) {
this.email = email;
}
@Email @IgnoreValidation
public String getEmail() {
return email;
}
}
Of course, this would be equivalent to removing the BV annotations; but it's often more convenient (debugging, etc.) to disable than to remove. This annotation could potentially be used on an Application sub-class (i.e., class representing a JAX-RS app) to disable all annotations globally in JAX-RS.
Has this requirement been proposed by any of the other technologies integrating with BV?
Thanks.
-- Santiago
On Jun 27, 2012, at 6:19 PM, Gunnar Morling wrote:
> Hi Santiago,
>
> what we currently do have is an annotation, @MethodValidated [1],
> which can be used to specify how method validation shall be applied
> for a given type.
>
> Our current thinking is that Bean Validation itself wouldn't evaluate
> this annotation and trigger method validation. Instead this would be
> done by the integrating technology, here JAX-RS. So also this
> integrating technology would be in charge of globally
> enabling/disabling method validation.
>
> Based on that, I'm seeing two options now:
>
> * JAX-RS checks resources for the annotation and performs method
> validation for those types/methods, where the annotation is found
> * JAX-RS performs method validation by default for all resources, also
> if the annotation is not given. The annotation could be used to
> disable method validation for specific resources if needed
> (@MethodValidated(validationMode=NONE))
>
> Would this work for you (I think you expressed doubts about
> validationMode=NONE at one point, but I'm not sure)? If not, could you
> describe the scenario you have in mind a bit more?
>
> Btw., since last week there is a first alpha release of the BV 1.1 RI,
> which also implements the current method validation draft. Maybe you
> could give it a try and see how it works for your use case? This would
> be a great opportunity to see whether the new APIs fit.
>
> --Gunnar
>
> [1] http://beanvalidation.org/1.1/spec/#validationapi-triggeringmethodvalidation
> [2] http://in.relation.to/Bloggers/FirstAlphaReleaseOfHibernateValidator5
>
>
> 2012/6/27 Santiago Pericas-Geertsen <Santiago.PericasGeertsen_at_oracle.com>:
>> Hi Gunnar,
>>
>> 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.
>>
>>
>> Have you given any more thought to this issue? I.e., the ability to
>> globally turn validation on/off?
>>
>>
>> I don't know though, whether there is such global descriptor for JAX-XS.
>>
>>
>> We don't have one. If BV does not provide a mechanism for this, we'll
>> likely need to define a new annotation in JAX-RS to disable validation.
>>
>> Thanks.
>>
>> -- Santiago
>>