Validating with multiple errors

[Karl Koster]

When I test JSON with multiple errors (e.g. bad enumerations, missing properties, violations in ranges) I only get the first error. Is it possible to get all errors, or at least as many as possible before validation continuation is impossible?

[Francis Galiegue]

Hello,

Can you show the code you are using? There are ways to get all errors
(although the API is rather sketchy currently). Also, what version of
the API do you use?

--
Francis Galiegue, fgal...@gmail.com, https://github.com/fge
JSON Schema in Java: http://json-schema-validator.herokuapp.com
Parsers in pure Java: https://github.com/parboiled1/grappa (redde
Caesaris: https://github.com/sirthias)

[Karl Koster]

Francis:

I am on the version 2.2.5 of json-schema-validator, While I cannot show you the code (IP issues) what I am doing is creating a MessageBodyReader for Jersey that loads the schema on its constructor with the following code:

JsonSchemaFactory.byDefault().getJsonSchema(uri);

In the readFrom() method of the reader, I am reading off a JsonNode from the entity stream and passing it to the aforementioned schema for validation

final ProcessingReport report = schema.validateUnchecked(node, true);

The ProcessingReport returned only contains a single error even when I have unit tested with multiple errors in the JSON. I didn't see any specific settings either on the construction of the schema or the usage of it alter its error reporting. The wiki is pretty thin, and, if it is there, I missed it.

Thanks,

Karl

--
Karl Koster
karl....@gmail.com

[Francis Galiegue]

On Thu, Oct 16, 2014 at 12:11 PM, Karl Koster <karl....@gmail.com> wrote:
> Francis:
>
> I am on the version 2.2.5 of json-schema-validator, While I cannot show you
> the code (IP issues) what I am doing is creating a MessageBodyReader for
> Jersey that loads the schema on its constructor with the following code:
>
> JsonSchemaFactory.byDefault().getJsonSchema(uri);
>
> In the readFrom() method of the reader, I am reading off a JsonNode from the
> entity stream and passing it to the aforementioned schema for validation
>
> final ProcessingReport report = schema.validateUnchecked(node, true);
>
> The ProcessingReport returned only contains a single error even when I have
> unit tested with multiple errors in the JSON. I didn't see any specific
> settings either on the construction of the schema or the usage of it alter
> its error reporting. The wiki is pretty thin, and, if it is there, I missed
> it.
>

Can you paste the error, then?

Note that since you use .validateUnchecked, no (checked) exception can
be thrown, so your single message may actually be an Exception wrapped
into an error message.

Regards,

[Karl Koster]

Francis:

There is no error in an exception sense. The processing report simply returns the first schema validation it finds. In the case of the unit test it was an invalid value for an enumerated type which was expected.

Karl

[Karl Koster]

Francis:

Found the issue. The AnyOfValidator collects subreports of all schemas being validated against and only issues a single message if the entire collection of schemas fail to validate with an argument of 'reports' that contains all the the subreports by pointer/path. This makes sense and I missed the impact of this on my first "go round". I need to pull the 'reports' property off of the message and sort out which, if any, subreport to use. Thanks for responding so quickly to the prior posts. 

Thanks,

Karl

On Thursday, October 16, 2014 6:46:14 AM UTC-4, Francis Galiegue wrote:

[Karl Koster]

Is there any way, short of getting the entire message serialized as a JsonNode, of inspecting the arguments? I would rather request a specific argument from the ProcessingMessage (e.g. 'reports') and attempt to flatten out the messages that were issued. Better yet, it would be great if we could get the set of sub-reports as an collection (e.g. Collection<
ProcessingReport> message.subReports())

Any thoughts?

Karl

On Thursday, October 16, 2014 6:46:14 AM UTC-4, Francis Galiegue wrote:

[Karl Koster]

More on this topic. I am now inspecting the JsonNode that is created when asJson() is called on the ProcessingMessage that contains the nested ProcessingReports. However, when I attempt to deserialize the reports using Jackson's ObjectMapper as a ListProcessingReport I am getting the following error:

Unrecognized field "level" (class com.github.fge.jsonschema.core.report.ListProcessingReport), not marked as ignorable (2 known properties: "logLevel", "exceptionThreshold"])

It appears that the reports are serialized in a way that makes it impossible to deserialize them short of creating custom deserializers. Is this correct? If so, it makes decomposition of nested errors a bit messy since we would then need to know the internal implementation of the framework (i.e. how the reports/messages are constructed in JSON) and rely on that for parsing this state. It also introduces possible versioning issues if this internal state every changes.

Regard, 

Karl

On Thursday, October 16, 2014 6:46:14 AM UTC-4, Francis Galiegue wrote:

[Francis Galiegue]

Hello,

On Mon, Oct 20, 2014 at 2:50 PM, Karl Koster <karl....@gmail.com> wrote:
> More on this topic. I am now inspecting the JsonNode that is created when
> asJson() is called on the ProcessingMessage that contains the nested
> ProcessingReports. However, when I attempt to deserialize the reports using
> Jackson's ObjectMapper as a ListProcessingReport I am getting the following
> error:
>
> Unrecognized field "level" (class
> com.github.fge.jsonschema.core.report.ListProcessingReport), not marked as
> ignorable (2 known properties: "logLevel", "exceptionThreshold"])
>
> It appears that the reports are serialized in a way that makes it impossible
> to deserialize them short of creating custom deserializers. Is this correct?
>

Well, mea culpa on this one. This part of the code was made at a time
when I wasn't fluent with JSON {de,}serialization. Were I to redo it,
and I will, I'd use Jackson mechanisms for deserialization... Would it
only be because...

> If so, it makes decomposition of nested errors a bit messy since we would
> then need to know the internal implementation of the framework (i.e. how the
> reports/messages are constructed in JSON) and rely on that for parsing this
> state. It also introduces possible versioning issues if this internal state
> every changes.
>

... Of this.

Now, the problem would be to know what an API user would expect to do
with the messages...

[Karl Koster]

Report them back to the consumer of a REST endpoint so they can correct any errors on their submission and try again.

[Francis Galiegue]

On Fri, Oct 31, 2014 at 7:46 PM, Karl Koster <karl....@gmail.com> wrote:
> Report them back to the consumer of a REST endpoint so they can correct any
> errors on their submission and try again.
>

Uhmwell, I don't really see a problem then.

Reminder: JSON Schema is not tied to REST, nor to HTTP; it is protocol agnostic.

The way error messages are implemented right now, you have all the
needed information to proceed, or nearly so; you can have the messages
as JSON, and in these messages you have the keyword which fails, the
path into the schema and instance, the error message and additional
data. It is then "just" a matter of crawling through that JSON.

Admittedly, right now it is only a raw JSON without any specific
accessors; but then if I program specific accessors, is this what the
user will want ultimately?

Not that I shun the idea of an API for error messages; at this moment,
however, I just don't know what this API should be.