[bv-dev] Triggering method validation

[Gunnar Morling]

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