[bv-dev] missing api to evaluate @ValidateOnExecution

[Gerhard Petracek]

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 at 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 at 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 at 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 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/20130729/f1ea7bfb/attachment.html