This document discusses declarative input validation using JSR 303 and ExtVal. It begins by introducing the speaker and their background. It then discusses the DRY (Don't Repeat Yourself) principle and how validation is often repeated in Java EE applications. The document introduces JSR 303 as a way to standardize validation constraints and have the UI interpret and enforce them. It provides examples of validation code with and without JSR 303 annotations. The document discusses using ExtVal to add JSR 303 support to older versions of Java EE and JSF. It demonstrates features like cross-validation, setting violation severity, and creating custom annotations and validation strategies with ExtVal. Overall, the document promotes using annotation-based validation with ExtVal to create

1. Declarative input validation
with JSR 303 and ExtVal
April 13th, 2011 – Bart Kummel

2. Who am I?
● Bart Kummel
● 10 years experience
in software development
● Of which 6 years in Java EE
● Consultant @ Transfer Solutions,
Leerdam, NL
● Competence manager @
Transfer Solutions, Leerdam, NL
● Author of Apache MyFaces 1.2
Web Application Development
● See http://tinyurl.com/am12wad
2

3. Photo: Salar de Uyuni, Bolivia; © 2010 by Bart Kummel 3

4. Don’t Repeat Yourself
● Less code = less bugs
● Duplicated code = duplicated bugs
● Duplicated code = duplicated maintenance
● Dupliacted maintenance = forgotten maintenance
4

5. DRY violations in classic Java EE apps
● Validation is programmed in Model beans
● Because that’s where it belongs
● Validation is repeated in View layer
● Because you have to use JSF Validators
● Validation is even repeated multiple times in the View
● Because the same bean is used in multiple JSF pages
5

6. Let’s fix this
● Remove validation code from View
● Let View generate validation based on Model
How to fix it?
● That’s why Bean Validation (JSR 303) was created
6

7. JSR 303: the idea
● Standardized way to express validation constraints
● Any UI technology can interpret those constraints and enforce
them
● Non-UI technologies can also use the validation information
7

8. JSR 303: the idea implemented
● JSR 303 is part of Java EE 6
● The reference implementation is
Hibernate Validator 4.*
● See http://hibernate.org/subprojects/validator.html
● Hibernate Validator 4.* can also be used in Java EE 5
● A JSR 303 implementation is only the way to express the validation
constraints
● You don’t get UI validation logic if the UI framework
doesn’t support JSR 303
8

9. How to add Bean Validation to a Java EE 5 application
● Add Hibernate Validator 4.* as library
● ...and some extra libraries, provided in
the Hibernate Validator package
● Use JSR 303 annotations in your beans
● Use MyFaces ExtVal 1.2.* to add declarative
validation support to JSF 1.2
9

10. Bean Validation in Java EE 6
● No need to add a JSR 303 implementation
● JSR 303 is part of the Java EE 6 platform
● Use JSR 303 annotations in your beans
● JSF 2.0 has support for JSR 303 annotations out of the box
● But support is limited
● You can (and should!) still use ExtVal (2.0.*) and get lots of
benefits (more on that later)
10

11. Side note: ExtVal versioning
● There are three current versions of ExtVal
● 1.1.* for JSF 1.1
● 1.2.* for JSF 1.2
● 2.0.* for JSF 2.0
● The latest stable release is release 3
● That is: 1.1.3, 1.2.3 and 2.0.3
● Lots of exciting new stuff is going into the next version
● Snapshot releases of ExtVal are very high quality
11

12. Example: classic validation code in bean
private int capacity;
public void setCapacity(int capacity) {
if(capacity >= 0 && capacity <= 100000) {
this.capacity = capacity;
} else {
// throw exception
}
}
12

13. Example: JSR 303 annotations
@Min(0)
@Max(100000)
private int capacity;
public void setCapacity(int capacity) {
this.capacity = capacity;
}
enefits:
Extra b
– less code
eadable
– better r
13

14. Example: classic validation in JSF page
<h:inputText value="#{room.capacity}" >
<f:validateLongRange minimum = "0"
maximum = "100000" />
</h:inputText>
14

15. Example: no validation in JSF page!
<h:inputText value="#{room.capacity}" />
15

16. Demo 1:
Bean Validation basics in Java EE 6

17. So why do we need ExtVal?
● To use Bean Validation in Java EE 5 / JSF 1.2
● To have advanced options in Java EE 6
17

18. ExtVal on Java EE 6: advanced options
● Cross validation
● Violation severity
● i.o.w. give warnings instead of errors
● More flexibility in choice of annotations to use
● JSR 303, JPA, ExtVal, own annotation or any combination
● Customization on all levels, e.g.:
● Custom message resolvers
● Custom validation strategies demos
Custom meta data
coming
●
up!
18

19. Configuring ExtVal
● Just add the ExtVal .jar files to your project
19

20. Demo 2:
Adding the ExtVal .jar files to our project

21. Cross validation
● Examples of cross validation
● check if two values are equal
● check if date is before or after other date
● value is only required if other value is empty (or not)
● etcetera...
21

22. Demo 3:
Cross validation

23. Demo 3 – Summary
● @DateIs can be used for date-related cross validations
● Use DateIsType.before, DateIsType.after or
DateIsType.same
● Other cross validation annotations:
● @Equals and @NotEquals for equality-based cross validation of any
type
● @RequiredIf for conditional required fields
– Use RequiredIfType.empty or RequiredIfType.not_empty
23

24. Violation severity
● Give certain validation rules a severity level of “warning”
● A warning will be given to the user, but “invalid” data can be
submitted
24

25. Demo 4:
Setting violation severity to “warning”

26. Demo 4 – summary
● Violation severity is not part of the JSR 303 standard
● We use payload to add violation severity level as custom meta data
● JPA also interprets JSR 303 contraints before persisting data, but
does not recognise violation severity
● Solution: use ExtVal annotations instead
26

27. Customization on all levels
● ExtVal is full of customization hooks
● A lot of ready-made add-ons are available
● see http://os890.blogspot.com
27

28. Demo 5:
Creating a custom annotation and a
custom validation strategy

29. Demo 5 – summary
● Technically, creating a custom annotation is not an ExtVal feature
● It is just a Java feature
● We need an ExtVal validation strategy to make a custom
annotation work
● We need to map our annotation to our validation strategy
● We can create a startup listener for this
● As an alternative we can use ExtVal plugins to use alternative ways of
configuration
29

30. Summary
● With annotation based validation, we can
finally create DRY JSF applications
● ExtVal gives us the opportunity to use
annotation-based validation on Java EE 5
● On Java EE 6, ExtVal gives us:
● More powerful annotation-based validation
● More flexibility
30

31. More info...
● Workshop tomorrow: ‘Rule your model with Bean-Validation’
● 08:00 – 10:00, Room 2 – Gerhard Petracek
● I will put links to slides & demo code on my blog
● http://www.bartkummel.net
● Chapter 10 of MyFaces 1.2
Web Application Development
● http://tinyurl.com/am12wad
● MyFaces ExtVal:
● http://myfaces.apache.org/extensions/validator
● http://os890.blogspot.com/
31

32. Questions & answers
A wise man can learn more from a
foolish question than a fool can learn
from a wise answer.
Bruce Lee
32