[bv-dev] Triggering method validation

Gerhard Petracek gerhard.petracek at gmail.com
Fri Jan 27 06:53:43 EST 2012


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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20120127/2fa74cec/attachment.html 


More information about the beanvalidation-dev mailing list