from spec draft 1.0.Beta1:


Is it really needed to do this?

The proposed spec is giving a good advice, as I expect this to be usually correct, but in case I wanted to remove a validator in an ovverriden getter I can't, there would be no way to get rid of them.

I don't think people ovverride properties in entities very often, but in case someone had to override the method body he might want to override the annotations too; he would be 100% blocked.

What would be the alternative you propose? duplication?

The reason the spec is written like that is because from a OO point of view, this is the right thing to do.

Hi Emmanuel,

I don't like it either, but at least you get some choice.

I agree with you that this would be needed for clean code, I am just arguing that maybe you are enforcing a best practice.
Maybe it's a good thing, but if someday someone needs otherwise he will be stuck. Also in OO you you may override a method with a "throw new UnsupportedException", quite ugly but permitted.

I think it should be the default behavior, but you could consider a way to optionally disable it.

What about an annotation similar to ?
You add a new "marking annotation", then you could add it to all default validators and recommend it to be used on all user-provided validator.

You could also make a default wrapping validator which is not marked, so people could "wrap" standard validators to disable inheritance; something like the "@Properties" in your examples but accepting a single validator instead of an array.

regards,
Sanne

quoting myself:

I'm sorry I tried to implement a prototype and didn't manage to implement the wrapping validator, I wonder if it's possible;
I'm not an annotations expert, but it looks like I can't wrap another annotation without binding a specific one.
Is there any known trick for that? Would it be possible with WebBeans?

Anyway just adding the marking annotation could give enough flexibility.

Sanne

not the wrapper is not doable in Java.

I am thinking that a property level @StopValidationInheritence might do the trick.

You're right I was thinking of marking the annotations, but you get much better decoupling and flexibility marking the property.