[bv-dev] Constructor validation

[Emmanuel Bernard]

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 at 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 at 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 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
> 
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev