 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
 JSRs: Java Specification Requests
JSR 303: Bean Validation
JCP version in use: 2.7 Java Specification Participation Agreement version in use: 2.0 Description: This JSR will define a meta-data model and API for JavaBeanTM validation based on annotations, with overrides and extended meta-data through the use of XML validation descriptors. Please direct comments on this JSR to the Spec Lead(s) Team
List of compatible implementations. The following information has been updated from the original proposal. 2007.11.14: Specification Lead: Emmanuel Bernard, Red Hat Middleware LLC E-Mail Address: emmanuel.bernard Telephone Number: +1 404 729 2254 Fax Number: - Original Java Specification Request (JSR)
Identification |
Request |
Contributions
Section 1. Identification Submitting Member: Jason Carreira Name of Contact Person: Jason Carreira E-Mail Address: jcarreira Telephone Number: - Fax Number: - Specification Lead: Jason Carreira E-Mail Address: jcarreira Telephone Number: - Fax Number: - NOTE that this information has been updated from this original proposal.
Initial Expert Group Membership: JBoss Supporting this JSR: JBoss Section 2: Request
2.1 Please describe the proposed Specification:Validating data is a common task that is copied in many different layers of an application, from the presentation tier to the persistentce layer. Many times the exact same validations will have to be implemented in each separate validation framework, proving time consuming and error-prone. To prevent having to re-implement these validations at each layer, many developers will bundle validations directly into their classes, cluttering them with copied validation code that is, in fact, meta-data about the class itself. This JSR will define a meta-data model and API for JavaBean validation. The default meta-data source will be annotations, with the abilty to override and extend the meta-data through the use of XML validation descriptors. It is expected that the common cases will be easily accomplished using the annotations, while more complex validations or context-aware validation configuration will be available in the XML validation descriptors. The validation API developed by this JSR will not be specific to any one tier or programming model. It will specifically not be tied to either the web tier or the persistence tier, and will be available for both server-side application programming, as well as rich client Swing application developers. 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. 2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)Java Standard Edition / Java Enterprise Edition 2.3 The Executive Committees would like to ensure JSR submitters think about how their proposed technology relates to all of the Java platform editions. Please provide details here for which platform editions are being targeted by this JSR, and how this JSR has considered the relationship with the other platform editions.The target platform is Java SE 5. Should this JSR be voted on by both Executive Committees?No 2.5 What need of the Java community will be addressed by the proposed specification?This work will address the need of the Java community for standardized validation meta-data and a standard validation API. This meta-data will be valuable across a number of application domains, from Swing desktop applications to web applications and the persistence layer. 2.6 Why isn't this need met by existing specifications?Existing specifications touch on validation or offer domain-specific validation, but none offer a reusable validation framework which can be used across application domains. 2.7 Please give a short description of the underlying technology or technologies:This JSR, like many in the post-JDK 1,5 world, seeks to define meta-data about objects using a combination of annotations and XML descriptors. In addition this JSR will provide a runtime validation framework to check JavaBean property values against the validations defined for them. 2.8 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)Not known at this time. 2.9 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?No 2.10 Are there any security issues that cannot be addressed by the current security model?No 2.11 Are there any internationalization or localization issues?Validation messages should be able to be localized, but this can be handled using standard ResourceBundles. 2.12 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?No 2.13 Please describe the anticipated schedule for the development of this specification.The intention is to deliver this JSR as a component of Java SE 7 (code name "Dolphin"). Early Draft Review would occur in the second half of 2006, Public Review in the first half of 2007, and Proposed Final Draft in the second half of 2007. 2.14 Please describe the anticipated working model for the Expert Group working on developing this specification.The primary means of communication will be email, with conference calls and face-to-face meetings scheduled as needed. 2.15 It is important to the success of the community and each JSR that the work of the Expert Group be handled in a manner which provides the community and the public with insight into the work the Expert Group is doing, and the decisions that the Expert Group has made. The Executive Committees would like to ensure Spec Leads understand the value of this transparency and ask that each JSR have an operating plan in place for how their JSR will address the involvement of the community and the public. Please provide your plan here, and refer to the Spec Lead Guide for a more detailed description and a set of example questions you may wish to answer in your plan.An implementation of the spec will be developed as a public opensource project, either at java.net or Apache. As part of the project infrastructure a public web page will be regularaly updated with questions specific to the implementation. All questions and concerns raised by the community will be answered in a timely manner. As necessary, questions will be forwarded to the EG mailing lists. 2.16 Please describe how the RI and TCK will de delivered, i.e. as part of a profile or platform edition, or stand-alone, or both. Include version information for the profile or platform in your answer.This JSR will initially be delivered standalone. However it is hoped that it will also be bundled into a future Java SETM release. Any future revisions of this JSR will only be delivered as part of Java SE. 2.17 Please state the rationale if previous versions are available stand-alone and you are now proposing in 2.13 to only deliver RI and TCK as part of a profile or platform edition (See sections 1.1.5 and 1.1.6 of the JCP 2 document).N/A 2.18 Please provide a description of the business terms for the Specification, RI and TCK that will apply when this JSR is final.The license will be a free-of-charge open source license. Section 3: Contributions
3.1 Please list any existing documents, specifications, or implementations that describe the technology. Please include links to the documents if they are publicly available.XWork Validation Framework (http://wiki.opensymphony.com/display/XW/Validation+Framework) Commons-Validator (http://jakarta.apache.org/commons/validator/) Hibernate Validator (http://www.hibernate.org/hib_docs/annotations/reference/en/html/validator.html) 3.2 Explanation of how these items might be used as a starting point for the work.The listed validation frameworks demonstrate possible solutions to some of the listed issues, and shows that a solution is possible in principle. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
