Re: [bv-dev] Constructor validation

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