[bv-dev] Triggering method validation

[Gunnar Morling]

> imo we should also talk with other expert-groups about the basic idea.

Absolutely. Emmanuel/I had already some discussions with folks from the CDI
and JAX-RS EGs.

JSF is definitely a good point, I hadn't considered that so far. Do you
know who would be good to talk to?

Am 27.01.2012 12:54 schrieb "Gerhard Petracek" <gerhard.petracek at gmail.com>:
>
> hi @ all,
>
> imo we should also talk with other expert-groups about the basic idea.
> e.g. the jsf-eg (i'm going to propose group-validation triggered via
command components (based on a feature of myfaces extval) and maybe they
have additional ideas related to this topic.)
>
> regards,
> gerhard
>
>
>
>
> 2012/1/27 Hardy Ferentschik <hardy at hibernate.org>
>>
>> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20120127/a5d683ef/attachment-0001.html