imo we should provide the api as well as the corresponding tests early (at least as an information until we have bv.next).

regards,
gerhard



2013/7/26 Gunnar Morling <gunnar@hibernate.org>
Hi,

To give some background: the idea was to let integration frameworks decide which executables should be validated to allow for consistency with their own rules for interceptor enablement and request processing; e.g. JAX-RS validates getter-style resource methods by default, or a DI framework might have its own annotation for controlling validation or descriptor format for registering interceptors.

Based on that, @ValidateOnExecution (and the settings in XML) is provided as the *recommended* way of controlling executable validation but its not obligatory: "This section expresses the behavior that integration with interception frameworks should follow. Any deviation should be considered with care as it will surprise Bean Validation users."

That being said, I agree that adding a facility for retrieving these settings via the BV API makes sense to make life easier for those integrators wishing to adhere to the BV behavior; integrators with deriving behavior could still use this API as input for their evaluation.

--Gunnar


2013/7/26 Emmanuel Bernard <emmanuel@hibernate.org>
I will let Hardy and Gunnar answer that one, this has been discussed a lot and some arguments they provided lead to delegate the rules implementations to the integration framework.

On 25 juil. 2013, at 22:55, Gerhard Petracek <gerhard.petracek@gmail.com> wrote:

> hi @ all,
>
> currently every framework which needs to integrate (bv based) method-validation has to implement the rules specified for @ValidateOnExecution itself.
> there is no method in the api for delegating the evaluation to the bv-implementation (and everything passed to ExecutableValidator gets validated
> independent of the xml based or annotation based config).
>
> it isn't just a higher effort for such frameworks, it (already) leads to inconsistencies across frameworks.
> -> imo it should be one of the first topics for bv.next.
>
> regards,
> gerhard
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev

_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev


_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev