gerhard

2011/12/2 Gunnar Morling <gunnar.morling@googlemail.com>

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@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@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@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@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
>>
>> _______________________________________________
>> 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