Validation of arbitrary map

[Trenton]

I'm processing documents. Several processors (zip, image processing) hidden inside the processing process, which do not have a general clear structure of arguments. The coming request may look like:

{
    "sourceDocumentId": "b4e8d214-9473-4d41-83c9-06e5491c18d3",
    "pipeline": [
        {
            "processor": "image",
            "arguments": {
                "pipeline": [
                    {
                        "processor": "resize",
                        "arguments": {
                            "width": 200,
                            "height": 150
                        }
                    },
                    {
                        "processor": "crop",
                        "arguments": {
                            "width": 100,
                            "height": 100,
                            "snap": "center"
                        }
                    }
                ]
            }
        },
        {
            "processor": "zip",
            "arguments": {
                "compression": "HIGH"
            }
        }
    ]
}

All of this case is required to validate (the existence of a processor with a given name, the support of mime-type throughout the rations, that the next processor takes out mime-type, the correctness of the arguments) to deny the client prior to the commencement of the processing in the event of misappropriation, and it is assumed that the addition of a new processor is merely an addition to a new interface in the container. How can such a validation be arranged on the basis of the hibernate holder?

[derk]

As a result, the task has been accomplished by selective (but, in my view, the right) means.

The above-mentioned payload consumes with jackson, and I wrote a simple function to convert the structure to specific classes. There are interfaces in the application container DocumentProcessor and ImageProcessor (first accepted) InputStream and OutputStreamthe second... BufferedImagewhich clearly indicate the name and type of object of the arguments. In the case of steam, the caste deserizer first examines the unloading of these realities in the container, takes a particular processor out of the discharge, retracts the appropriate class of arguments from the processor, searches for the caste deserializer of this class, if found, deserialyizes it, and if not, uses it. ObjectMapper To convert arguments into the right type. Thus, a processor known as the above-mentioned payload is in the processor "image", it's a type of argument, there's an appropriate desserylizer, it's called, the desserylizer gets to the input Map, deserializes it in the intermediate facility. List<{processor:string, arguments:map}>for each processor Looking for a container of arguments (if not found, using a default container based on a map) for each container looking for a dessertizer, after which the desserylizer or the use of a deserver finally starts. ObjectMapper for desserization.
The exit system is very blunt and inflexible, but as a result, a rigid structure can be removed easily by simple annotations. Jackson himself offers http://wiki.fasterxml.com/JacksonPolymorphicDeserialization which greatly facilitates the work, but in this draft it was decided to give up on it for some reasons.

The question of validation remains open.