Invalid serialisation of UnionTypeSchema

[tapina]

UnionTypeSchema currently cannot be serialised because it returns a null type which is not welcomed by JsonSchemaIdResolver.idFromValue. If you extend UnionTypeSchema and return a type then it serialises this as "type" and serialises the types as "elements". This is not valid JSON Schema. It should serialize the union as a "type" array. See https://tools.ietf.org/html/draft-zyp-json-schema-03#page-8

If I then attempt to further patch UnionTypeSchema to change "elements" into "type" then it serialises with TWO "type" properties which isn't even valid JSON!

If I attempt to annotate UnionTypeSchema to not include type info with @JsonTypeInfo(use = JsonTypeInfo.Id.NONE, property = "type") then it has no effect except when the union type schema is passed directly to ObjectMapper.

A test case is attached.

JacksonUnionTypeSerializationBugTest.java.txt

[cowtowncoder]

This is tricky due to multiple reasons; one being that JsonFormatTypes is defined as enum, is not extensible, and does not have UNION value. Perhaps it should. The whole way this module was designed is pretty fragile unfortunately. I am not sure what can be done at this point.

[cowtowncoder]

Hmmmh. Was about to add UNION type (will revert)... but then realized that this would not work the way intended.

The thing is, serialization of Type Id by Jackson will never be able to produce arbitrary structures; so if true union types are desired, handling MUST be completely rewritten. And specifically, I don't think there will ever be support to use/consume JSON Array of type ids.

If anyone cares enough to work on this (I basically do not use JSON Schema myself, and do not have personal interest, beyond hoping to help others), I think the model to follow would be delegation/converter, so that intermediate value would be JsonNode, and then type could be extracted from tree representation, in whatever value format, and instance constructed using treeToValue() call (or similar). This is all quite easily accessible via DeserializationContext.

One challenge is that such a change would be backwards compatible only via JSON produced/consumed, as type of type Java class(es) would change. This may or may not be significant problem.

[tapina]

We're using JSON schema quite extensively for self-describing REST APIs (with self-building web CRUD UIs), although we're only using serialization. As it seem like we're the only people in the world actually using this, I'd be happy to try a fork and submit some pull requests that address some of the issues we've had.

[cowtowncoder]

@tapina That would be great. I should be able to help with details at least; and having unit tests is a good first step any way; we can add them under failing first (to prevent blocking builds). And conversion of polymorphic type handling for schemas would be important, if big change. It would also allow addition of new custom schema types as necessary -- use of Enums is convenient but non-extensible.

[tapina]

Enums can certainly be a pain. Indeed to work around one of the limitations of the module around value formats I had to create some horrible code to dynamically modify the relevant enum at runtime (who knew you even could?!). Being able to contribute some code to the project to get rid of that monstrosity would take away the bitter taste that lingers with me...

Gareth

On 30 Dec 2015, at 18:13, Tatu Saloranta notifications@github.com wrote:

@tapina That would be great. I should be able to help with details at least; and having unit tests is a good first step any way; we can add them under failing first (to prevent blocking builds). And conversion of polymorphic type handling for schemas would be important, if big change. It would also allow addition of new custom schema types as necessary -- use of Enums is convenient but non-extensible.

—
Reply to this email directly or view it on GitHub.

[cowtowncoder]

Yeah, enums are a tricky choice. Impressive hack on replacing enums at runtime, did not realize that is possible. One can at least make enums implement an interface, which is sometimes useful for finding balance between extensibility... but there are many limitations.