Re: [bv-dev] Constructor validation

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(a)hibernate.org&gt;: > 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(a)web.de&gt; 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&lt;sebastian.thomschke(a)web.de&gt;: >>>> 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 > > _______________________________________________ > 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