We just released the Bean Validation 2.0 release train (e.g. the specification, the API and the TCK) for the Final Approval Ballot and, as usual, we release a compatible version of Hibernate Validator shortly after: here comes Hibernate Validator 6.0.0.CR3.
We just released a CR2 of the Bean Validation 2.0 release train (e.g. the specification, the API and the TCK) and, as usual, we release a compatible version of Hibernate Validator shortly after: here comes Hibernate Validator 6.0.0.CR2.
Hibernate Validator 6 is going to be the Reference Implementation of Bean Validation 2.0.
This Beta1 release is coordinated with the 2.0.0.Beta1 release (Public Review Draft) of the Bean Validation specification.
It is also a playground used to validate future enhancements of the Bean Validation specification so feedback on the subjects presented here is very welcome!
Note that Hibernate Validator 6 requires JDK 8 or above.
WildFly, as a compatible Java EE 7 implementation, comes with Bean Validation 1.1 and its reference implementation Hibernate Validator 5 out of the box.
In the following we’ll show you how easy it is to upgrade the server’s modules to the latest Bean Validation release, using a patch file provided by Hibernate Validator.
Today we’ll be talking about Hibernate Validator and how you can provide your own constraints
and/or validators in a fully self-contained manner. Meaning packaging it all into its own JAR file,
in a way that others can use your library by simply adding it to the classpath.
What can be a real life scenario for building your own library with constraints and sharing it? Well, let’s say that
you are building some library with data classes that user might want to validate. As it may be tough
to keep track of all such libraries and write/maintain all those constraints for them - Hibernate
Validator provides authors of such libraries a possibility to write and share their own validation extensions.
Which can be picked up by Hibernate Validator and used to validate your data classes.