See: Description
This package provides an infrastructure to chain individual units of work (processors) together in order to produce arbitrarily complex processing chains. The provided infrastructure is complete with processing messages, reports and dedicated exceptions.
In addition, it also provides a basic set of structures to work with JSON Schema: trees and schema trees, JSON Reference, schema syntax validation and schema walking (with associated listeners and processors), schema loading.
A Processor is a base unit
of work. Its concept is pretty simple: it accepts an input as an argument and
produces an output.
For reporting purposes, it also has a ProcessingReport as an argument, to which
you can log messages.
All the processing infrastructure is in the following package: jsonschema.core.processing.
You can combine processors in several ways:
You can therefore create arbitrarily complex chains. And, last but not least,
you also have the ability to transparently cache the results of a processor if
the computation is expensive, for future reuse -- not only that, but you can
also provide an Equivalence on inputs to reduce
the set of inputs cached.
The two basic components of the reporting/logging infrastructure are ProcessingReport and ProcessingMessage.
The existing infrastructure allows you to:
All the logging infrastructure is in the following package: jsonschema.core.report.
A processing report has a classical set of logging methods, which names will
be familiar to anyone having used a logging API: debug(), info(), warn() and error(). You can customize what log levels
are effectively logged, but also from what level exceptions are thrown instead.
As ProcessingReport is an
interface, you can actually use a logging system for your messages -- or even
log messages at different levels differently; however, be aware that the
contract is rather strict (but it is documented), and as such you may prefer to
extend AbstractProcessingReport instead.
This package comes with three implementations built in: ConsoleProcessingReport (which logs to
the standard output), ListProcessingReport (which accumulates
messages in a list} and DevNullProcessingReport (which discards
all messages but keeps track of the processing status).
Messages have one main source: processor inputs. You will have noticed that
both inputs and outputs are required to implement the MessageProvider interface: this allows
reporting message templates to be generated out of an input and, as such, helps
greatly in identifying what the source of the message is, and therefore at what
step in the processing this message has been issued.
Another customization of logging messages is exception generation: when the
message is logged at a level which raises an exception rather than being
purely logged, AbstractProcessingReport does not throws per se, but calls this message's .asException() instead. If you
have customized the processing message with a specific exception provider, this
means your custom exception will be thrown rather than the standard ProcessingException.
This package allows to build JSON References from string inputs or URI instances. You can also resolve one reference against another and
obtain the fragment part (if the JSON Reference is legal) as a JSON Pointer.
The main use of this package in the core is to materialize URI contexts in
JSON Schema instances. A special form (non URI compliant) of reference exists
to be able to handle jar URIs as well.
All JSON Reference related classes are in the following package: jsonschema.core.ref.
Classes in the jsonschema.core.load package serve
several purposes:
All aspects of schema loading are controlled via a LoadingConfiguration
instance.
JSON Schema requires that regular expressions obey the ECMA 262 regular expression dialect. This package, thanks to its dependency on Rhino, provides full compliance.
For this purpose, the RhinoHelper
class allows you to test whether a string is a valid ECMA 262 regular
expression, but also to test whether a string matches a given regex.