[bv-dev] Constructor validation

[Sebastian Thomschke]

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