[bv-dev] Triggering method validation

Gunnar Morling gunnar.morling at googlemail.com
Fri Jan 27 10:18:48 EST 2012


One potential issue I see here is that "method validation" can also be
applied to constructors.

One aspect of this is wording in the spec. There we should IMO have a
preamble saying something like "method level validation can refer to
methods and constructors." Another thing is the annotation name we're
trying to find. Something like @ValidateMethods suggests IMO that no
constructor validation is performed, or at least leaves room for
interpretation.

So maybe @ValidateConstraints?

Generally I think adjectives make better binding annotation names
(@Transactional being a good example) instead of imperative names like
the ones discussed so far. In Seam Validation it's hence named
@AutoValidating. That's surely not perfect, too, but maybe someone has
another idea based on that?

--Gunnar

2012/1/27 Hardy Ferentschik <hardy at hibernate.org>:
> @ValidateMethodCall,
>
> but any of these three would work for me
>
> --Hardy
>
> On Jan 27, 2012, at 3:25 PM, Emmanuel Bernard wrote:
>
>> @ValidateMethods
>> @ValidateOnMethodCall
>> ?
>>
>> On 27 janv. 2012, at 12:13, Hardy Ferentschik wrote:
>>
>>> Thanks Gunnar for the explanation. It made things much clearer (at least for me).
>>> Maybe my confusion was also caused by the fact that @ValidateGroups was so
>>> generically named. I don't think it really expresses its intend. Wouldn't something like
>>> @MethodValidated be better?
>>>
>>> --Hardy
>>>
>>>
>>> On Jan 26, 2012, at 9:29 PM, Gunnar Morling wrote:
>>>
>>>> 2012/1/26 Hardy Ferentschik <hardy at hibernate.org>:
>>>>
>>>>> On Jan 22, 2012, at 8:33 PM, Gunnar Morling wrote:
>>>>>> Instead this should be task of technologies integrating the method
>>>>>> validation feature to decide whether a validation is needed or not and
>>>>>> if so delegate that validation to BV.
>>>>>
>>>>> Right. My understanding was that if method level validation is enabled in the integrating
>>>>> framework and method level annotations exist, validation gets triggered.
>>>>
>>>> Yepp, I think there are different interpretations of "enabling method
>>>> validation" floating around which might cause some irritations. There
>>>> are actually two "levels" of enablement IMO:
>>>>
>>>> * A system is generally able to make use of method validation by
>>>> providing the required integration layer. Taking CDI for example,
>>>> there would be a CDI method interceptor which is able to intercept
>>>> method calls and invoke Validator#validateParameters() and/or
>>>> Validator#validateReturnValue().
>>>> * Based on that integration layer, method validation is actually
>>>> enabled (or not) for given types. In other words instead of enabling
>>>> method validation globally for all types/methods, I think often a more
>>>> fine-grained configurability is required. Sticking to the CDI example,
>>>> the types to perform method validation on, would be annotated with an
>>>> interceptor binding annotation which causes the validation interceptor
>>>> to kick in if methods on the annotated type are invoked. Taking Spring
>>>> AOP as example, the types for which to perform method validation on
>>>> could be specified using an advice with type name patterns,
>>>> restrictions to certain packages etc.
>>>>
>>>>>> #2 Define an annotation such as @javax.validation.ValidateGroups within BV
>>>>>>
>>>>>>     @ValidateGroups({Group1.class, Group2.class})
>>>>>>     public class OrderService {
>>>>>>
>>>>>>             @NotNull
>>>>>>             public Order placeOrder(@NotNull(groups=Group1.class) @Size(min=3,
>>>>>> max=20) String customerCode, @NotNull Item item, @Min(1) int quantity)
>>>>>> { //... }
>>>>>>
>>>>>>     }
>>>>>
>>>>> What would @ValidateGroups in this case do?
>>>>
>>>> @ValidateGroups would be the second "enabler" from the two above. That
>>>> is, it controls that method validation shall be performed on the
>>>> methods of OrderService by means of the validation interceptor
>>>> provided by the given integration layer. It would also control which
>>>> groups should be validated for methods invoked on the annotated type
>>>> (here Group1 and Group2). It furthermore might control whether to
>>>> perform a parameter or return value validation or both.
>>>>
>>>> This is comparable to declarative transaction control; there exists an
>>>> interceptor which is able to begin/commit transactions. To which
>>>> types/operations this interceptor applies can be controlled using an
>>>> annotation such as @Transactional (or other means such as an XML
>>>> config).
>>>>
>>>>>> #3 Don't define anything related in BV, leave that completely to integrators
>>>>>
>>>>> That is probably the solution I had in mind from the beginning. Seems still most reasonable to me.
>>>>
>>>> That's definitely an option, but it might cause a proliferation of the
>>>> JEE platform. There are several potential integrators of method
>>>> validation (I know at least about CDI and JAX-RS). They could all
>>>> define their own variant of @ValidateGroups, but these would likely be
>>>> very similar to each other. So another option is to define one
>>>> standardized annotation for that purpose in BV which then can be used
>>>> by all interested integrators. For instance
>>>>
>>>> * JAX-RS would check for that annotation on REST resource classes and
>>>> would invoke j.v.Validator upon invocation of resource methods
>>>> * CDI would define a CDI method interceptor and handle the annotation
>>>> as interceptor binding annotation which causes the interceptor to kick
>>>> in using the standard CDI mechanisms for interceptor handling
>>>>
>>>>>> Taking CDI for example, AFAIK the annotation would have to be annotated with the @InterceptorBinding meta annotation. I don't know whether/how it would be possible that we define the "basic" annotation, while integrators "enrich" it with the meta data they require.
>>>>
>>>> In between I had the chance to talk to Pete from the CDI EG. He
>>>> confirmed that annotation types can programmatically be "promoted" to
>>>> interceptor binding annotations. That means CDI could integrate with
>>>> an annotation type defined in the BV API also if that type hasn't the
>>>> @InterceptorBinding meta annotation (which it shouldn't IMO in order
>>>> to avoid a compile dependency from BV to CDI).
>>>>
>>>> --Gunnar
>>>>
>>>> _______________________________________________
>>>> beanvalidation-dev mailing list
>>>> beanvalidation-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>>
>>>
>>> _______________________________________________
>>> beanvalidation-dev mailing list
>>> beanvalidation-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>
>>
>> _______________________________________________
>> beanvalidation-dev mailing list
>> beanvalidation-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev



More information about the beanvalidation-dev mailing list