The information you provide here will be included in the Open Liberty beta blog post (example), which will be published on openliberty.io/blog/, and potentially elsewhere, to promote this beta feature/function of Open Liberty. For this post to be included in the beta issue please make sure that this is completed by the end of Friday following the GM (Tuesday). The beta and release blogs are created using automation and rely on you following the template's structure. DO NOT REMOVE/ALTER THE <GHA> TAGS THROUGHOUT THIS TEMPLATE.
Please provide the following information:
Which Liberty feature(s) does your update relate to?
Human-readable name (eg WebSockets feature): Jakarta Validation
Short feature name (eg websockets-1.0): beanvalidation-3.1
Who is the target persona? Who do you expect to use the update? eg application developer, operations.
Application Developer
Provide a summary of the update, including the following points:
A sentence or two that introduces the update to someone new to the general technology/concept.
What was the problem before and how does your update make their life better? (Why should they care?)
Briefly explain how to make your update work. Include screenshots, diagrams, and/or code snippets, and provide a server.xml snippet.
Where can they find out more about this specific update (eg Open Liberty docs, Javadoc) and/or the wider technology?
Jakarta Validation provides a mechanism for validating constraints imposed on Java objects using annotations. The most noticeable change in version 3.1 is the name change, from Jakarta Bean Validation to just Jakarta Validation. There is also explicit support for validating Java Records, which were added in Java 16. Records reduce a lot of the boilerplate code in simple data classes, and pairs nicely with Jakarta Validation.
public record Employee(@NotNull String empid, @Valid EmailAddress email) {}
Employee employee = new Employee("12432", new EmailAddress("mark@example.com"));
Set<ConstraintViolation<Employee>> violations = validator.validate(employee);
</GHA-BLOG-SUMMARY>
What happens next?
Add the label for the beta you're targeting: target:YY00X-beta.
Make sure this blog post is linked back to the Epic for this feature/function.
Your paragraph will be included in the beta blog post. It might be edited for style and consistency.
You will be asked to review a draft before publication.
Once you've approved the code review, close this issue.
If you would also like to write a standalone blog post about your update (highly recommended), raise an issue on the Open Liberty blogs repo. State in the issue that the blog post relates to a specific release so that we can ensure it is published on an appropriate date (it won't be the same day as the beta blog post).
The information you provide here will be included in the Open Liberty beta blog post (example), which will be published on openliberty.io/blog/, and potentially elsewhere, to promote this beta feature/function of Open Liberty. For this post to be included in the beta issue please make sure that this is completed by the end of Friday following the GM (Tuesday). The beta and release blogs are created using automation and rely on you following the template's structure. DO NOT REMOVE/ALTER THE
<GHA>TAGS THROUGHOUT THIS TEMPLATE.Please provide the following information:
Which Liberty feature(s) does your update relate to?
Human-readable name (eg WebSockets feature): Jakarta Validation
Short feature name (eg websockets-1.0): beanvalidation-3.1
Who is the target persona? Who do you expect to use the update? eg application developer, operations.
Application Developer
Provide a summary of the update, including the following points:
A sentence or two that introduces the update to someone new to the general technology/concept.
What was the problem before and how does your update make their life better? (Why should they care?)
Briefly explain how to make your update work. Include screenshots, diagrams, and/or code snippets, and provide a
server.xmlsnippet.Where can they find out more about this specific update (eg Open Liberty docs, Javadoc) and/or the wider technology?
Jakarta Validation provides a mechanism for validating constraints imposed on Java objects using annotations. The most noticeable change in version 3.1 is the name change, from Jakarta Bean Validation to just Jakarta Validation. There is also explicit support for validating Java Records, which were added in Java 16. Records reduce a lot of the boilerplate code in simple data classes, and pairs nicely with Jakarta Validation.
What happens next?
target:YY00X-beta.