3:25 p.m.
Yes, I see. I'm not really sure, what we can do about this except
making this very clear in the spec/documentation.
After all it's the same thing with "normal" constraints, such as
property constraints. Only adding a constraint to a property doesn't
cause it to be validated automatically.
Or did you have something else in mind?
2011/12/1 Emmanuel Bernard <emmanuel(a)hibernate.org>:
Yes. That concerns me a bit to be honest especially when more
technologies will offer BV integrations. We need to think this through before opening
pandora's box even more :)
On 1 déc. 2011, at 21:48, Sebastian Thomschke <sebastian.thomschke(a)web.de> wrote:
> Ok gotcha.Maybe we should make it clear in the specs that adding
> parameter constraints does not necessarily mean when such a
> constructor/method is invoked from somewhere in unmanaged code that an
> instant validation will happen, but that the time of validation and if a
> validation happens at all depends on the validator implementation.
>
> Regards,
> Seb
>
> On 01.12.2011 21:32, Gunnar Morling wrote:
>> Hi Sebastian,
>>
>> is this really something which we should consider in BV?
>>
>>> From my point of view we should only provide an API for
>> method/constructor validation (by adding
>> Validator#validateMethodParameters() for instance), but we shouldn't
>> provide a trigger/hook executing this validation. I'd see this as the
>> responsibility of technologies integrating with BV (similar to the
>> existing validate() methods which are invoked by JSF/JPA if
>> applicable).
>>
>> So whether method validation is triggered via a proxy, CDI/Spring AOP
>> interceptor etc. should be transparent for BV IMO.
>>
>> I wasn't sure about whether there is an actual need for constructor
>> validation, but Emmanuel's answer about JAX-RS confirmed that need :)
>>
>> --Gunnar
>>
>>
>> 2011/12/1 Sebastian Thomschke<sebastian.thomschke(a)web.de>:
>>> Supporting constructor parameter validation as well as validation of
>>> parameters of methods not part of an interface requires some sort of
>>> byte code enhancements and cannot be done via JDK proxying.
>>> So if we find a sufficient solution how to achieve method parameter
>>> validation without JDK proxies I do not see why we should not support
>>> constructor parameter validation too.
>>>
>>> Regards,
>>> Seb
>>>
>>> On 30.11.2011 19:59, Gunnar Morling wrote:
>>>> Hi experts,
>>>>
>>>> Emmanuel asked me to take the lead on the method validation feature,
>>>> so be prepared for related questions, API proposals and requests for
>>>> feedback via the mailing list :)
>>>>
>>>> The first issue I'd like to discuss is the validation of constructor
>>>> arguments. Is this something which we want to support at all? I
don't
>>>> think there are that many interception solutions which enable
>>>> constructor interception at all (for instance CDI interceptors
don't,
>>>> AFAIK).
>>>>
>>>> So personally I'd be fine with focussing on actual method validation
>>>> in BV 1.1, waiting for user demand for constructor validation and
>>>> adding it possibly in a later release. WDYT?
>>>>
>>>> If we decide to include constructor validation, should we support the
>>>> validation of newly created objects (similar to return value
>>>> validation), e.g. like that:
>>>>
>>>> public class Foo {
>>>>
>>>> @Valid
>>>> public Foo() {
>>>>
>>>> }
>>>>
>>>> }
>>>>
>>>> Here @Valid would trigger a validation of the newly instantiated Foo
>>>> object (whether to use @Valid or another annotation still needs to be
>>>> discussed). Any thoughts?
>>>>
>>>> --Gunnar
>>>> _______________________________________________
>>>> beanvalidation-dev mailing list
>>>> beanvalidation-dev(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>> _______________________________________________
>>> beanvalidation-dev mailing list
>>> beanvalidation-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>> _______________________________________________
>> beanvalidation-dev mailing list
>> beanvalidation-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev