4:25 a.m.
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(a)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(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