[bv-dev] Constructor validation

[Gerhard Petracek]

+1

regards,
gerhard



2011/12/2 Gunnar Morling <gunnar.morling at 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 at 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 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
> >
> > _______________________________________________
> > 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/20111202/88c0c715/attachment.html