[bv-dev] Overriding constraints in inheritance hierarchies

[Gunnar Morling]

Yep, it's certainly in the nice-to-have category. I created BVAL-2^8
[1] so we can address this whenever we feel like.

--Gunnar

[1] https://hibernate.onjira.com/browse/BVAL-256


2012/1/3 Emmanuel Bernard <emmanuel at hibernate.org>:
> At one point the spec had an annotation akin to @IgnoreInheritedConstrains that applied on the target of the constraint
>
> ```
> public class A { @Size(min = 1, max = 10) private String field1; @Min(2) private Integer field2; ... }
>
> @ConstraintOverrides({
> @ConstraintOverride(name="field1", constraint={@Size(min=4, max =20)}),
> @ConstraintOverride(name="startDate", constraint={@Min(1)})
> })
> public class B extends A {
>    @IgnoreInheritedConstrains @Size(min=4, max =20)
>    String getField1() { ...  };
>
>    @IgnoreInheritedConstrains @Min(1)
>    Integer getField2() { ...  };
>
>
> }
> ```
>
> We removed it for a few reasons the main ones being that we could not find a good use case for it. It was mainly used to fix mistakes made in superclasses. I'm not against it but we need a use case.
>
> Note that the field overriding must be done on the getter which is a bit weird in Java but makes sense in the "property" world of Bean Validation. If Java had proper properties or even overridable fields t would not be a problem. That's an irregularity of the Java language though.
>
> I also like Matt's proposal a lot which is essentially captured in BVAL-229 but that's a nice to have feature. I'm afraid we will be short of time for this release.
>
> Emmanuel
>
> On 2 janv. 2012, at 22:43, Matt Benson wrote:
>
>> One, albeit heavy-handed, way to approach this type of requirement
>> isimplemented by the code
>> athttp://svn.apache.org/viewvc/incubator/bval/sandbox/bval-jsr303-dynamic/.
>>  This ValidationProvider provides a DynamicValidatorContext that canbe
>> customized using its #constrain(Class, Annotation)
>> and#constrain(Class, String, Annotation) methods.  The mechanism
>> forhandling Annotation parameters is extensible, so one potential use
>> ofthis functionality is the removal of existing constraints.  This
>> mightprovide enough surface area to fuel a discussion on this type
>> offunctionality for a future version of the spec.
>> Matt
>> On Mon, Jan 2, 2012 at 1:39 PM, Gunnar Morling
>> <gunnar.morling at googlemail.com> wrote:
>>> Hi experts,
>>>
>>> just recently there was a ticket created in the HV tracker [1] which
>>> suggests to provide a way for "overriding" constraints within
>>> inheritance hierarchies, i.e. the constraints defined on a property of
>>> a parent bean are re-defined on the same property on an inherited bean
>>> type (instead of being added up).
>>>
>>> The approach suggested in the ticket doesn't work as described there,
>>> as it isn't possible to define a generic array of constraint
>>> annotations. Nevertheless it might be useful to have a means of
>>> disabling the constraints from super types in special cases.
>>>
>>> That said, I personally didn't have that requirement yet, but it makes
>>> sense to me that someone might find this useful.
>>>
>>> Any thoughts?
>>>
>>> --Gunnar
>>>
>>>
>>> [1] https://hibernate.onjira.com/browse/HV-548
>>> _______________________________________________
>>> 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