Let me summarize the questions and problems we had while implementing JSR303 based on the early-darft spec. I try so list the points as short as I can with references to the chapters in the spec:

* chapter 2.1:
In some code examples, @ValidatorClass is used instead of @ConstraintValidator => typo?

* Some APIs seem quite annotation-centric

==> what to do when constraintdescription originates from a xml file / is not based on annotations?

* chapter 5.2: Is ElementDescriptor.getElementType() ambiguous? Isn't this rather an access-strategy per constraint than per property?

validator.getConstraintsForProperty(“name”).getElementType() => FIELD or METHOD? (@NotEmpty: FIELD, @Length: METHOD)

* chapter 3.1.2: Do you plan to explain whether or not annotation of setter-methods is supported (access strategy would be unclear)?

* chapter 3.1.2: How is the access-strategy for annotated overwritten methods:



==> is method A#getName() called? I don't think so.

* 3.5 validation routine: Is it really neccessary to specify that field level validations are executed BEFORE property level validations or should this be an implementation detail instead?
Because: Sequence can be defined with groups/groupsequences. In case of InvalidConstraints found, validation will not stop until the group is completly validated anyway.

* chapter 3.4: I had problems understanding the required behaviour for groupSequence handling:
InvalidConstraint.groups: String instead of String[] to contain the group, where the invalidconstraint has occurred?

* chapter 4.1.1: Validator.validateProperty() + Validator.validateValue(propertyName,value,groups...)
can propertyName contain a propertyPath (with dot-notation)?

* chapter 3.1.3: How will the @Valid annotation determine the target type , especially in case of to-many relationships? (Invoke getClass() on each instance in the collection? Using reflection on the generic collection type can be a problem when generic type is Object or some interface type.) I would suggest to add an optional attribute like “hint”/”id” or “targetClass” to the @Valid annotation. That would open up the possibility to have a different validation per association role:


Best regards
Roman

Yep, typo due to a last minute change.


Generate the annotation. Annotations are the meta model today.



I agree, I noticed that. AFAIR it has some implications, but we need to address that.



setter annotation are not supported, does it read differently?


A#getName() is not called as it would require some bytecode manipulation, but constraints on A#getName() will be called. In your example @NotEmpty will be checked twice
This is explained in 3.3.


Why do you think the wording in 3.5 implies an order between field and method? I does not.


This is not very well defined. The thing is I am not sure we can define that property (especially because of the group sequence expendability). We are looking for feedback on the usefulness of this feature.


Do you think it is useful?



No this is a runtime resolution. We probably need to be be more clear about that.

Thanks for your feedback

Hello Emmanuel,

thanks for your reply that clarified most of the issues I mentioned (and helped us to update our JSR303 implementation).

Let me answer to two points from your reply:

I agree, but in this case it means: code generation, doesn't it?
The point is (similar to post "Non-intrusive constraint declaration"), that annotations are bound 1:1 to a type while the flexible validation solution we are using contains the feature to have different validation definitions per class without modification of the source. Basic validations (e.g. based on constraints of the database) can be expressed by annotations, others can be added like decorators on higher application layers and may differ when customizing the application for different clients (also during runtime). They are currently based on XML. How could those constraints appear in the metadata request APIs?


Maybe the API becomes more "symmetric" when you can re-validate with the beanClass/rootBean/value/propertyPath values from the InvalidConstraint. Why should the API offer the ability to validate some single properties while others cannot be validated separately just because they are inside a child object? But this is of low priority in my opinion.


Best regards
Roman

Not really, an annotation is an interface, you can create a proxy implementing annotations


Let me know what you think of
http://in.relation.to/Bloggers/BeanVali ... Validation


The problem is that '.something' means both getter and field.
We have the problem already when limited to one level though

Yes, OK.



Ok, I see, that the concept of groups can solve most of the issues.

I am curious about how the runtime resolution of associated beans will be described in the final spec..

What do you mean?

What I meant by "I am cursious about the specification of runtime resolution" is, that on one hand, you need a class to construct a Validator:

but on the other hand, an object in the relationship will probably be validated by its concrete runtime type.
So what happens if I validate a subclass of Person with a validator created for Person.class? Does it validate the Person-attributes only?
Will validation work properly for associated objects, then the getter's or field's type is just java.lang.Object (or some Interface)? To validate a to-many relationship, each instance's type must be determined (sending each.getClass(), even it is a dynamic proxy) and a proper validator must be created.
Why is a Class-object required to create the initial ClassValidator, when the framework needs to be more dynamic for validation of associated objects?
I just wait for the next release of the spec and see if it clarifies this a little.

Thanks for your attention. Regards, Roman

Ah yes that's a good point.
The association must have dynamic determination.
The API is cleaner when a type is used but I am not sure it is that useful considering what you said. I've added a note.
So you would trop the generic altogether?

As far as I understand the intention of the draft-spec, the generic in interface Validator<T> is a good thing for a clean API. But the passage in chapter 4.1:



should be dropped, because it implies that the constructor argument Class<T> is used to determine the initialization of the Validator (but as we already discussed the Validator must be more dynamic anyway). So the spec needs not mention restrictions on the constructor - a zero-arg constructor would be ok, too and the interface Validator<T> can keep the generic.

But caution: when the Validator is constructed without a class-argument, the metadata-request-API must also change, because methods like "hasConstraints", "getBeanConstraints", "getConstraintsForProperty", "getValidatedProperties", need a parameter (Class) then.

With best regards
Roman

Yes, my main concern is that without generics, you cannot access the metadata APIs, so we might still keep the generic version around.