[bv-dev] Constructor validation

[Gunnar Morling]

>>> 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?>
> Could we have an example for this? I don't quite get what this is about.
Let's assume there is a bean with some property constraint:

public class Foo {

  private int bar;

  @Min(5) public int getBar() { return bar; }

  public void setBar(int bar) { this.bar = bar; }

}

If this bean is subject to method validation, the @Min constraint will
be validated automatically when getBar() is invoked (assuming some AOP
layer executing the validation is in place).

The idea now was to provide some option to apply the constraint also
to the parameter of the setBar() method. That way invalid Foo
instances couldn't be created at all. Of course one simply could add
the constraint manually to the parameter, but given that this might be
a rather common use case, it might be good to have a less redundant
way for this.

Some possible ways:

#1 A class-level annotation:

@ApplyPropertyConstraintsToSetters
public class Foo {

}

#2 A property level annotation:

public class Foo {

  @ApplyToSetter
  @Min(5)
  public int getBar() {
    return bar;
  }
}

#3 An option in the configuration API:

Validator validator = Validation.byDefaultProvider()
        .configure()
        .applyPropertyConstraintsToSetters()
        .buildValidatorFactory()
        .getValidator();

2011/12/7 Hardy Ferentschik <hardy at hibernate.org>:
>
>>>> 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?
>
> +1 for option #2
>
>
>>>> @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.
>
> I guess you can solve the problem with groups somehow, but this probably means that you have to pull all your method constraints into a group. As you already say, it is not elegant.
> I think something like @IsInvariant or @InvariantOnly is a much more expressive solution and is also backward compatible. We are just extending existing functionality.
>
>
>>>> 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.
>
>>> 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?
>
> Could we have an example for this? I don't quite get what this is about.
>
> --Hardy
>
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev