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

short addition: @constructor (validation): for sure the performance issue only appeared as soon as we started to use it for classes which get instantiated quite often. regards, gerhard http://www.irian.at Your JSF/JEE powerhouse - JEE Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/11/30 Gerhard Petracek <gerhard.petracek(a)gmail.com&gt; > > hi gunnar, > > @constructor: > we tried something similar in a project. it worked but it introduced a big > performance issue and we had to remove it again. > > regards, > gerhard > > http://www.irian.at > > Your JSF/JEE powerhouse - > JEE Consulting, Development and > Courses in English and German > > Professional Support for Apache MyFaces > > > > > 2011/11/30 Gunnar Morling <gunnar.morling(a)googlemail.com&gt; >> >> 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

From my point of view we should only provide an API for

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

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

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

Constraints you add to a property are constraints that are used to determine an object's state (valid or invalid). Constraints you add to parameters are preconditions and must be satisfied before the method body is allowed to be executed. So yes, I think there is a semantic difference. Now the question is in which cases are those preconditions evaluated? When you manually invoke the method somewhere in your code or only when the method is invoked explicitly via e.g. a DI framework that itself utilizes BV. As long as this is addressed in the specs I'm fine. In OVal for example preconditions are only evaluated automatically when your project is setup for programming by contract correctly as documented here: http://oval.sourceforge.net/userguide.html#programming-by-contract Other interesting aspects regarding constructor/method validation that should be addressed are: - do we support parameters on static methods?

- which visibilities do we support? public, private, package, protected? all?

- inheritance: you pass a java.lang.Method object of class A to validateMethodParameters() and an object of class B extending class A which overrides this method. Which constraints are checked, the ones of the method declared on class A, the ones declared on the method of class B or the sum of the methods in A & B?

- When you add a method return value constraint to a parameterized method and you do Validator.validate(object), thoses constraints are not evaluated. But when you add a constraint to a getter-style method (which also looks and actually is a method return value constraint). They are evaluated by Validator.validate(object). What if someone wants to add a method return value constraint to a getter-style method, that is not evaluated when Validator.validate(object) is executed but after the method itself has been invoked? In OVal you have to explicitely add the @IsInvariant annotation to getter methods if their constraints should be evaluated too when Validator.validate(object) is executed. If so, OVal will invoke the getter and test the returned value against the constraints specified.

Regards, Seb On 02.12.2011 22:25, Gunnar Morling wrote: > 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&lt;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&lt;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 _______________________________________________ beanvalidation-dev mailing list beanvalidation-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/beanvalidation-dev

> > - inheritance: you pass a java.lang.Method object of class A to > validateMethodParameters() and an object of class B extending class A > which overrides this method. Which constraints are checked, the ones of > the method declared on class A, the ones declared on the method of class > B or the sum of the methods in A & B? That's a very good question. In fact in Hibernate Validator we don't support parameter constraints in overriding methods at all (so if A#foo() has parameter constraints, B#foo() must not declare any parameter constraints), as this represents a strengthening of preconditions in sub-types for clients of A, which violates the Liskov substitution principle. Some more reasoning can be found in the HV reference guide in section 8.3.1.1 [1]. I'm preferring this approach, though it is rather conservate. Some "programming by contract" solutions deal with this by OR-ing the preconditions in a method's hierarchy (so an invocation would be valid, if the constraints at A#foo() OR B#foo() are satisfied), actually applying the "weakest" contract in the hierarchy. How is this done in OVal? And does anyone know how it is in Apache BVAL?

> - When you add a method return value constraint to a parameterized > method and you do Validator.validate(object), thoses constraints are not > evaluated. But when you add a constraint to a getter-style method (which > also looks and actually is a method return value constraint). They are > evaluated by Validator.validate(object). What if someone wants to add a > method return value constraint to a getter-style method, that is not > evaluated when Validator.validate(object) is executed but after the > method itself has been invoked? In OVal you have to explicitely add the > @IsInvariant annotation to getter methods if their constraints should be > evaluated too when Validator.validate(object) is executed. If so, OVal > will invoke the getter and test the returned value against the > constraints specified. Personally I'd say getters are methods such as any other methods, too. So if a getter method is invoked one some bean generally qualifying for method validation (however that is decided by the method validation integration layer) the method's constraints should be validated in the same way as any other method constraints. If the bean is validated using Validator#validate(), the getter method's constraints should be handled as property constraints as it's the case today IMO.

In HV we are currently allowing to define additional return value constraints on methods overridden in sub types, and so far I haven't heard of any problems with that. AFAICS that's also what most programming by contract solutions do.

>> Note that return type constraints could be refined theoretically and be compliant with the Liskov substitution principle. We might want to still disallow this to limit confusion. It will all depend on the set of use case we can think of. > > In HV we are currently allowing to define additional return value > constraints on methods overridden in sub types, and so far I haven't > heard of any problems with that. AFAICS that's also what most > programming by contract solutions do. > > What's your opinion on parameter constraints? Would you prefer to > OR-join them or to prohibit constraints in overridden methods at all? I am neutral to against in the ground that it's not exactly trivial to understand and that the fact that return values behave differently is counter-intuitive even if it's logical. My logic applies for letting returned type be refined. We have three options: 1. not allow refinement 2. allow return value refinement (AND style) 3. allow param (OR style) and return value (AND style) refinement We can go from 1 to 3 in the lifetime of the spec but not back. What do others think? Could we work out 3-5 use cases for each to better see the merit of refinement?

>> @IsInvariant is not much different from a group (though a bit more elegant). I don't think we should add something explicit in the spec to address this problem as we already can solve it with groups.

>> Note that getters are not like ordinary methods, they are (by convention) Java properties and that's exactly what validator.validate processes (properties).

> An additional idea would be some option to apply a getter's > constraints also as method parameter constraints on the corresponding > setter. So if method validation for that bean is enabled, illegal > values couldn't be set at all. Would that be useful? Global setting or local setting?

>>>> >>>> Note that getters are not like ordinary methods, they are (by convention) Java properties and that's exactly what validator.validate processes (properties). > > Not all getters are necessary properties. Yes they are :)

From a pure spec point of view you are right.

>> Note that return type constraints could be refined theoretically and be compliant with the Liskov substitution principle. We might want to still disallow this to limit confusion. It will all depend on the set of use case we can think of. > > In HV we are currently allowing to define additional return value > constraints on methods overridden in sub types, and so far I haven't > heard of any problems with that. AFAICS that's also what most > programming by contract solutions do. > > What's your opinion on parameter constraints? Would you prefer to > OR-join them or to prohibit constraints in overridden methods at all? I am neutral to against in the ground that it's not exactly trivial to understand and that the fact that return values behave differently is counter-intuitive even if it's logical. My logic applies for letting returned type be refined. We have three options: 1. not allow refinement 2. allow return value refinement (AND style) 3. allow param (OR style) and return value (AND style) refinement We can go from 1 to 3 in the lifetime of the spec but not back. What do others think? Could we work out 3-5 use cases for each to better see the merit of refinement?

> >>>> - When you add a method return value constraint to a parameterized >>>> method and you do Validator.validate(object), thoses constraints are not >>>> evaluated. But when you add a constraint to a getter-style method (which >>>> also looks and actually is a method return value constraint). They are >>>> evaluated by Validator.validate(object). What if someone wants to add a >>>> method return value constraint to a getter-style method, that is not >>>> evaluated when Validator.validate(object) is executed but after the >>>> method itself has been invoked? In OVal you have to explicitely add the >>>> @IsInvariant annotation to getter methods if their constraints should be >>>> evaluated too when Validator.validate(object) is executed. If so, OVal >>>> will invoke the getter and test the returned value against the >>>> constraints specified. >>> >>> Personally I'd say getters are methods such as any other methods, too. >>> So if a getter method is invoked one some bean generally qualifying >>> for method validation (however that is decided by the method >>> validation integration layer) the method's constraints should be >>> validated in the same way as any other method constraints. If the bean >>> is validated using Validator#validate(), the getter method's >>> constraints should be handled as property constraints as it's the case >>> today IMO. >> >> @IsInvariant is not much different from a group (though a bit more elegant). I don't think we should add something explicit in the spec to address this problem as we already can solve it with groups. >> Note that getters are not like ordinary methods, they are (by convention) Java properties and that's exactly what validator.validate processes (properties). > > Yes, getters are considered as properties for standard bean validation > (Validator#validate()). But in the context of method validation I > would handle them as return value constraints as on any other method. > > If I understand correctly, @IsInvariant as described above would be > breaking with the current spec behavior as it is needed to explicitly > enable a constraint on a getter for property validation, which is in > BV the case by default. > > Using groups for cases, where a getter's constraints should be handled > different for property and method validation seems reasonable to me, > too. I have a small concern with that. Granted is compatible with the spec but if people have been investing in constraints that are validated at specific time, should we carry them by default as legit method constraints validated upon calls (that's assuming some AOP style interception)? > > An additional idea would be some option to apply a getter's > constraints also as method parameter constraints on the corresponding > setter. So if method validation for that bean is enabled, illegal > values couldn't be set at all. Would that be useful? Global setting or local setting? _______________________________________________ beanvalidation-dev mailing list beanvalidation-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/beanvalidation-dev

> An additional idea would be some option to apply a getter's>> constraints also as method parameter constraints on the corresponding>> setter. So if method validation for that bean is enabled, illegal>> values couldn't be set at all. Would that be useful?>> Global setting or local setting?

>> Note that return type constraints could be refined theoretically and be compliant with the Liskov substitution principle. We might want to still disallow this to limit confusion. It will all depend on the set of use case we can think of. > > In HV we are currently allowing to define additional return value > constraints on methods overridden in sub types, and so far I haven't > heard of any problems with that. AFAICS that's also what most > programming by contract solutions do. > > What's your opinion on parameter constraints? Would you prefer to > OR-join them or to prohibit constraints in overridden methods at all? I am neutral to against in the ground that it's not exactly trivial to understand and that the fact that return values behave differently is counter-intuitive even if it's logical. My logic applies for letting returned type be refined. We have three options: 1. not allow refinement 2. allow return value refinement (AND style) 3. allow param (OR style) and return value (AND style) refinement We can go from 1 to 3 in the lifetime of the spec but not back. What do others think? Could we work out 3-5 use cases for each to better see the merit of refinement? > >>>> - When you add a method return value constraint to a parameterized >>>> method and you do Validator.validate(object), thoses constraints are not >>>> evaluated. But when you add a constraint to a getter-style method (which >>>> also looks and actually is a method return value constraint). They are >>>> evaluated by Validator.validate(object). What if someone wants to add a >>>> method return value constraint to a getter-style method, that is not >>>> evaluated when Validator.validate(object) is executed but after the >>>> method itself has been invoked? In OVal you have to explicitely add the >>>> @IsInvariant annotation to getter methods if their constraints should be >>>> evaluated too when Validator.validate(object) is executed. If so, OVal >>>> will invoke the getter and test the returned value against the >>>> constraints specified. >>> >>> Personally I'd say getters are methods such as any other methods, too. >>> So if a getter method is invoked one some bean generally qualifying >>> for method validation (however that is decided by the method >>> validation integration layer) the method's constraints should be >>> validated in the same way as any other method constraints. If the bean >>> is validated using Validator#validate(), the getter method's >>> constraints should be handled as property constraints as it's the case >>> today IMO. >> >> @IsInvariant is not much different from a group (though a bit more elegant). I don't think we should add something explicit in the spec to address this problem as we already can solve it with groups. >> Note that getters are not like ordinary methods, they are (by convention) Java properties and that's exactly what validator.validate processes (properties). > > Yes, getters are considered as properties for standard bean validation > (Validator#validate()). But in the context of method validation I > would handle them as return value constraints as on any other method. > > If I understand correctly, @IsInvariant as described above would be > breaking with the current spec behavior as it is needed to explicitly > enable a constraint on a getter for property validation, which is in > BV the case by default. > > Using groups for cases, where a getter's constraints should be handled > different for property and method validation seems reasonable to me, > too. I have a small concern with that. Granted is compatible with the spec but if people have been investing in constraints that are validated at specific time, should we carry them by default as legit method constraints validated upon calls (that's assuming some AOP style interception)? > > An additional idea would be some option to apply a getter's > constraints also as method parameter constraints on the corresponding > setter. So if method validation for that bean is enabled, illegal > values couldn't be set at all. Would that be useful? Global setting or local setting? _______________________________________________ beanvalidation-dev mailing list beanvalidation-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/beanvalidation-dev

On 7 déc. 2011, at 22:32, Gunnar Morling wrote: >>> An additional idea would be some option to apply a getter's>> constraints also as method parameter constraints on the corresponding>> setter. So if method validation for that bean is enabled, illegal>> values couldn't be set at all. Would that be useful?>> Global setting or local setting? > > Haven't thought that far :) Probably both would make sense. Globally > via the configuration API, locally via an annotation, for instance. I'm personally not a big fan. I'm afraid of noisy constraints

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