Hello,

First of all thanks for making this JSR, we've been using Hibernate
Validator for production work and it has almost all we want. Since this
JSR addresses the same problems with very similar solutions, we're very
happy about it.

We have issues with InvalidConstraint though because once we validate
our persistent entities, we have a hard time mapping validation errors
to UI fields.
To be clearer: suppose we have a "name" bean property which fails
validation, we want to put an error message in the UI next to our "name"
input field. We may be able to gather the name of the bean property from
the InvalidConstraint.getPropertyPath() but it's a field which requires
parsing in order to get information.

Now suppose we have decided to put bean class validation methods in the
bean itself, with several methods annotated with @AssertTrue. For those
validation errors we would like to be able to specify that the
validation is the entire bean, not just the property annotated with
@AssertTrue (which is just a placeholder for validation, not for a
value).

I think InvalidConstraint should include more information about the
error. Putting the validation metadata (the validation annotation which
caused the error) as well as the property type (field, method, class)
would certainly be useful. The InvalidConstraint.getPropertyPath()
should be defined in a way which does not require parsing.

For instance if getPropertyPath() would return "field1.field2" we should
be able to query the validation annotations (or constraints) that failed
on "field2", and whether "field1" is a method or a field, same for
field2.

If we have that we can also differenciate validations cases such as:

class Foo{
@NotNull
Bar bar;
}

@MyValidator
class Bar{
}

Where both a "NotNull" and "MyValidator" validation errors would be
reported with property path "bar" I think.

Thanks.

I suspect some kind of EL engine can access the field for you. Generally speaking, some ui framework would probably like to add some sort of indirection between a property name and a field name (depending on the philosophy).


Why did you do that (as opposed to a class level constraint?
Others have requested to be able to ahve multiple fields per constraint failure, this mught help in your case.


How should it be? I would welcome type safety.
Keep in mind that Incalidconstraint will probably need to be serializable, this limit what you want / can add.




What is the use case you have in mind?

If we have that we can also differenciate validations cases such as:



They both are differenciated as they do not come from the same object root. the uniqueness comes from the tuple propertypath / root object.

As you cna see, I am interested in the use cases that lead to your requests.

Why we did several @AssertTrue methods in one class as opposed to class-level validation? First the validation is very specific to each class, so abstracting it to another place would not allow us to reuse it anyways. The second reason is that we like to have our model defined in the same entity as its validation constraints. If we have 10 different types of class-level validation checks we cannot possibly reveal their entire purpose using an annotation name. Putting them each in @AssertTrue methods within the entity allows us first to have a different localised message for each validation check, and second to keep the validation logic close to the model so they stay in sync.


I'm sorry, I am going to answer to the rest, but I need to think it through some more :)

Re-reading the specs, I guess on page 25 (section 4.2) you mention putting a pointer to metadata. That would solve my problem.

If I get

public interface InvalidConstraint<T> {
...
// the element on which the constraint failed
ElementDescriptor invalidElementDescriptor;

// the constraint which failed
ConstraintDescriptor invalidConstraintDescriptor;
}

I can figure out whether one InvalidConstraint is a property failure or a class-level validation done in a @AssertTrue validation method. It takes some routing, but it is doable.

I guess we don't need the Validator<T> in there because we have T in InvalidConstraint.getBeanClass() so we can look it up, no?

Is there no scope in the JSR to describe validation exceptions that would be triggered by other layers such as JPA ?
It would be really great that if JPA triggers automatic validation the Exception type is specified. Actually since several frameworks might want to do automatic validation, I think this Exception API should be defined in this JSR 303. (InvalidStateException containing an array of InvalidConstraint would be good enough for me).

Also since other frameworks/layers are expected to automate this validation, how would be instruct them of the "groups" to validate? We can already specify orders for groups, but not which groups automatically I think...

Why would you need the validator on a failure report?



It's an interesting question, we might push a proposed exception but fundamentally, each client can react ho it pleases him. If you think about JSF, you don't want an exception but a message in an html page.


This will most likely vary from one client framework to an other.
JSP would probably use the persistence.xml file, JSF use a tag, WebBeans use (maybe) an annotation.

To differentiate our @AssertTrue methods which are really class-level validation.



True, but you could state it another way: if a framework cannot handle automated validation failure, it should raise XXXException containing ...
This way, JSF or JSP which would be able to reject forms which don't validate would not be bound to make exceptions whereas the JPA layer would generate some standard exception to handle. We're really struggling at the moment trying to catch Hibernate Validation exceptions and JPA validation exceptions (nullable, unique, etc) from a JAX-RS (JSR311) server endpoint and some sort of official unified exception would help.



Yes. makes sense, thanks :)