We decided to do another release of the 5.1 series to fix critical bugs to be included in an upcoming version of WildFly. This may be the last release of the 5.1 series, so we recommend that you migrate to 5.2 for future bugfixes.
One thing you don’t hear enough about in the microservices world is data.
There is plenty of info on how your application should be stateless, cloud native, yadayadayada.
But at the end of the day, you need to deal with state and store it somewhere.
I can’t blame this blind spot.
Data is hard.
Data is even harder in a unstable universe where your containers will be killed randomly and eventually.
These problems are being tacked though in many fronts and we do our share.
But once you have dealt with the elasticity problem, you need to address a second problem: data evolution.
This is even more pernicious in a microservices universe where:
I’m glad to announce the second release of the Eclipse plugin for Hibernate Search.
In this post I’m describing the changes and new features of the release. Here you can find the first release blog post.
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.