Skip to content

Commit ac1c0ee

Browse files
committed
readme improvements
1 parent 954678f commit ac1c0ee

File tree

1 file changed

+89
-1
lines changed

1 file changed

+89
-1
lines changed

README.md

Lines changed: 89 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -12,7 +12,7 @@ Add the following to your `pom.xml`:
1212
<dependency>
1313
<groupId>org.everit.json</groupId>
1414
<artifactId>org.everit.json.schema</artifactId>
15-
<version>1.0.2</version>
15+
<version>1.1.0</version>
1616
</dependency>
1717
```
1818

@@ -32,4 +32,92 @@ try (InputStream inputStream = getClass().getResourceAsStream("/path/to/your/sch
3232
}
3333
```
3434

35+
Investigating failures
36+
----------------------
37+
38+
Starting from version `1.1.0` the validator collects every schema violations (instead of failing immediately on the first
39+
one). Each failure is denoted by a JSON pointer, pointing from the root of the document to the violating part. If more
40+
than one schema violations have been detected, then a `ValidationException` will be thrown at the most common parent
41+
elements of the violations, and each separate violations can be obtained using the `ValidationException#getCausingExceptions()`
42+
method.
43+
44+
To demonstrate the above concepts, lets see an example. Lets consider the following schema:
45+
46+
```
47+
{
48+
"type" : "object",
49+
"properties" : {
50+
"rectangle" : {"$ref" : "#/definitions/Rectangle" }
51+
},
52+
"definitions" : {
53+
"size" : {
54+
"type" : "number",
55+
"minimum" : 0
56+
},
57+
"Rectangle" : {
58+
"type" : "object",
59+
"properties" : {
60+
"a" : {"$ref" : "#/definitions/size"},
61+
"b" : {"$ref" : "#/definitions/size"}
62+
}
63+
}
64+
}
65+
}
66+
```
67+
68+
The following JSON document has only one violation against the schema (since "a" cannot be negative):
69+
70+
```
71+
{
72+
"rectangle" : {
73+
"a" : -5,
74+
"b" : 5
75+
}
76+
}
77+
```
78+
79+
In this case the thrown `ValidationException` will point to "#/rectangle/a" and it won't contain sub-exceptions:
80+
81+
```
82+
try {
83+
schema.validate(rectangleSingleFailure);
84+
} catch (ValidationException e) {
85+
// prints #/rectangle/a: -5.0 is not higher or equal to 0
86+
System.out.println(e.getMessage());
87+
}
88+
```
89+
90+
91+
Now - to illustrate the way how multiple violations are handled - lets consider the following JSON document, where both
92+
the "a" and "b" properties violate the above schema:
93+
94+
```
95+
{
96+
"rectangle" : {
97+
"a" : -5,
98+
"b" : "asd"
99+
}
100+
}
101+
```
102+
103+
In this case the thrown `ValidationException` will point to "#/rectangle", and it has 2 sub-exceptions, pointing to
104+
"#/rectangle/a" and "#/rectangle/b" :
105+
106+
```
107+
try {
108+
schema.validate(rectangleMultipleFailures);
109+
} catch (ValidationException e) {
110+
System.out.println(e.getMessage());
111+
e.getCausingExceptions().stream()
112+
.map(ValidationException::getMessage)
113+
.forEach(System.out::println);
114+
}
115+
```
116+
117+
This will print the following output:
118+
```
119+
#/rectangle: 2 schema violations found
120+
#/rectangle/a: -5.0 is not higher or equal to 0
121+
#/rectangle/b: expected type: Number, found: String
122+
```
35123

0 commit comments

Comments
 (0)