JSR 303 – Bean Validation

JSR 303 seeks to define a meta-data model and API for JavaBean validation. “This API is seen as a general extension to the JavaBeans object model, and as such is expected to be used as a core component in other specifications, such as JSF, JPA, and Bean Binding.”

A standardized validation API would be a great addition to the JDK. I’ve used a couple including Commons Validator and XWork’s bundled validation framework. These frameworks make life easier. However, like most things, there are no standards.

XWork’s implementation provides the ability to traverse the inheritance tree. It also allows for validation based on the context (method call). It comes with a number of validators, including stringlength, required, date. Validation can take place at field or non-field level. Fairly easy to use; I’ve only had issues when developing validation along with type-conversion for non-trivial objects. However, that is specific to web-based situations.

If the JSR will be based on XWork’s implementation, my major concern is the definition of a context. The previous definition of an aliasname does not exist in non-XWork specific implementations. Aliasname’s were simply the method name of an Action. This worked since Action execution methods were no-arg by convention. This concept will have to provide validation on method calls with arguments. By the nature of annotations, this will not be an issue. However, I am curious to see the XML-based solution. Last of all, I look forward to the ability to conditionally exclude validation based on the current context.

This entry was posted in Technical stuff. Bookmark the permalink.

4 Responses to JSR 303 – Bean Validation

  1. Pingback: Validation Framework Consolidation - Web 2.0 Squared Magazine

  2. Pingback: Sami Dalouche » Validation Framework Consolidation : where are we ?

  3. Anirudh Vyas says:

    My only issue is that they are going towards the route to integrate and standardize validation with Web Beans (JBOSS Seam replica ), This is needless to say annoyingly unecessary. Seam is a great work around for JSF, but i hate to say this; it simply doesn’t add up.

    And another question that pops up with me is; that if we have something like JSR 305 which attempts to standardize @Annotations for tools to detect ‘possible’ null errors / assignments etc (or validation if i can be a little bold here) at compile time (irrespective of how tools implement such a spec), How will they standardize this spec with the above one … like if i write @NotNull (from above JSR) should it be interpreted differently from the ones spec’d out in this ?

    (Only being concerned about syntax and how they would handle such a complexity internally can prove to be naive, imho, imagine a situation where you have two @NotNull to mean differently) …

    Vyas, Anirudh

  4. Pingback: that’s great… » JSR 303… 2 years later

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.