Hi there,
We are starting to use bean validation in our product and something we would like to do is what I’ve coined as “implicit constraints”. I’d like to run this by the mailing list and get your thoughts on this as a potential feature in
the spec.
The use case we have is we have a “DateTime” object which represents Date & Time. Our DateTime object pre-dates JDK 8 (and JodaTime). A DateTime for us has some constraints
- The DateTime cannot me before LOW_DATE à 01-01-1970 00:00:00
- The DateTime cannot me after HIGH_DATE à 31-12-2150 23:59:59
Not sure of the exact history of these constraints but it would seem like we are trying to invent a new y2k J
These constraints were enforced prior to our usage of Bean Validation as these were burnt into the setter of generated POJO’s (domain objects) but now that we are moving from generated domain objects to JPA style POJO’s we’d like
to use Bean Validation to apply the same constraints.
Assume we have an object which has a DateTime property as shown below
public class TestObject {
private DateTime myDateTime;
public DateTime getMyDateTime() {
return myDateTime;
}
public void
setMyDateTime(DateTime myDateTime) {
this.myDateTime
= myDateTime;
}
}
We’d like if developers did not need to add an annotation all DateTime properties to constrain with the implicit constraints.. i.e.
@Date
private DateTime myDateTime;
In our opinion this annotation serves no additional purpose and would be an extra onus on the developer to add this so they ensure the value meets internal DateTime criteria.
Looking at the 1.1 spec I cannot see any way of applying constraints without annotating (well you can use HV XML but that would need to be done for all fields).. Is that correct.
I’ve managed to implement “implicit constraints” by using non-standard Hibernate Validator API’s (i.e. using reflection I added an additional MetaDataProvider which added ConstrainedElements ( to the BeanConfiguration)). I can share
this on GitHub is anyone is interested in taking a look.
Appreciate any feedback you might have.
Thanks
Rich