Hi guys and gals,

I've been using JSR-303 for the past 3 years. Over this time, I've accumulated a list of issues that bother me with the current API:

1) It is impossible to define a constraint on a field that references another field. The typical use case would be a "confirm password" field for which a constraint such as @EqualsField("password") might be useful. Currently the only solution is a class-level constraint.

2) The whole bootstrapping architecture is cumbersome, IMO. I would like to see a system that's easily bootstrapped with a single call, without the need to specify the javax.validation.spi.ValidationProvider file. This is especially bad if one wants to override one class in the implementation. For instance, I needed to use my own ValidatorContext implementation; in order to do that, I had to create my own ValidationProvider implementation that returns my ValidationContext implementation and create the aforementioned provider file in the META-INF directory of my app.

3) I would like to see, at the API level, something similar to what the guys at Apache BVAL did - a separation between the way constraints are registered and the way they are stored inside the validation system. BVAL introduces the concept of a MetaBeanFactory, which can create constraints for a class (a "MetaBean") according to some form of registration - the default being annotations. This would allow one to register constraints programmatically at the API level.

To explain further on issue #3: at Wix, we wanted to be able to copy constraints from one class to another. That is, define constraints on one class and have them copied programmatically to another class depending on some imperative condition. Hibernate Validator does not allow one to do that, so we had to switch implementation to BVal, which causes its own issues since the project isn't very mature yet.

regarding item 3 -
I think what we need there is a standard Java API (part of the specification) to define constraints on a class.
The idea is to be able to define constraints using annotations or an equivalent API.

In some cases, the annotations are the way to go.
In other cases, the API.

However, the concept of validation is the same - given a class and a set of constraints (introduced via annotations or API), produce a validation result.

Hi,

thanks for taking the time to provide feedback and your input for BV 1.1, that's really much appreciated.

1) As you said there are class-level constraints, and personally I don't expect much to change here due to BV's strict emphasis of compile time type safety. Hibernate Validator provides a more ad-hoc alternative in form of @ScriptAssert, coming at the price of losing type safety. Would be interesting to know what Emmanuel thinks on adding something like that to BV :)

2) Specifying the SPI file is normally only required by BV implementations, and having a custom ValidatorContext seems like a very advanced scenario. Could you maybe give some more details on your use case? How would you imagine an alternative bootstrapping process?

3) You might want to add yourself as watcher for BVAL-229 which aims at providing an API for the definition of constraints. To get an impression how that might look like you might be interested in the programmatic constraint API offered by Hibernate Validator.

--Gunnar

Hi,

I propose two enhancement for BV 1.1:
[*] what is described in issue BVAL-225 http://opensource.atlassian.com/projects/hibernate/browse/BVAL-225.
[*] ability to invoke the Validator for a single or multiple constraint annotations from within a constraint implementation.

I explain the latter better: I'd like to implement "generic" constraints such as @AtMostOne, @AtLeastOne, @AtMostOneNot, @AtLeastOneNot to be used like this:

@AtMostOne(properties={"foo", "bar", "baz"}, constraints=@Size(max=10))

This would mean "apply the @Size(max=10) constraint to all the properties foo, bar, baz, and succeed in case at most one of the properties satisfy the condition, fail otherwise.

I believe this can be already done, but it's not as straightforward as it could be.

I propose passing the instance of the current validator to constraint implementation, and adding convinient method to the Validator interface, such as:
Validator.validate (String propertyName, Annotation... annotations).

(this can be probably emulated with Validator.validateValue, but you cannot specify a new non-existant constraint, only select and existing one using groups.

Regards,
Gabriele

agreed. that would be great

The problem I see is that there is no way to implement this in a generic and yet safe way afaik. The "constraints" member of @AtMostOne can't be defined in such a generic way that it would accept each kind of constraint (there can't be annotation members of type java.lang.annotation.Annotation).


Hmmm, how would you instantiate the annotations? Maybe the programmatic API (see BVAL-229) would address this request?

--Gunnar

Maybe you could provide a proposal how you would imagine the API?

--Gunnar

This is a great post it was very informative. I look forward to reading more of your work. So I made sure to bookmark your site so I can come back later. I enjoyed every minute of this reading
-------------------------------------
Septorinoplasti