Incomplete type definition for array/Collection properties

[cowtowncoder]

NOTE: cleaved off of #34

---

This bug seems not to be completely fixed. It doesn't throw a NPE anymore, but it doesn't generate the schema correctly either. It just generates:

{
    "type":"array"
}

I extended the test to use a collection of nested beans, and expected to see the schema of the nested items, e.g.:

    {
      "type" : "array",
      "items" : {
        "type" : "object",
        "properties" : {
          "property1" : {
            "type" : "integer"
          },
          "property2" : {
            "type" : "string"
          }
        }
      }
    }

See updated test: https://github.com/greyfairer/jackson-module-jsonSchema/commit/2a9b859fac14a412de68917655c9cf928d31d651

[mariepaulsen-sersol]

What's the status of this? From my experience, it looks like I can successfully create a schema from an object and then turn that into a json string, but then if I use an ObjectMapper to turn that back into a JsonSchema, all of my arrays get messed up. That's a big problem for me.

Is there anything I can do to help fix this or make the fix happen sooner?

[cowtowncoder]

I haven't had time to work on Schema module lately, so any help would be appreciated. Oftentimes the problem is in databind module, since most information is sent by JsonSerializer that handles the property. It is also possible that information piped through BeanPropertyWriter is incomplete. And of course, finally, it is also possible that JSON Schema visitors could be omitting something; but more commonly it is incoming metadata that is incomplete.

[mariepaulsen-sersol]

I'm afraid I'm not familiar enough with the code to fix it myself :-( I did a bit of debugging and comparing, and it certainly seemed like the two JsonSchemas (the original, and the one created from its string output) were different from each other and the second one had the oversimplified array items. So it seems to me that the problem is somewhere in converting the String to a JsonSchema, not in analyzing that JsonSchema.

Best guess is that the problem is in the com.fasterxml.jackson.module.jsonSchema.types.ArraySchema file, in Items.jsonCreator. I see a comment in there about another bug too.

[cowtowncoder]

@mariepaulsen-sersol I'll go and have a look at the updated tests; sometimes there are easy fixes to be found.

[mariepaulsen-sersol]

Oh . . . you were talking about serializing, I think the problem is in the deserialization of a schema json string into a JsonSchema object. My sequence:

1.

        ObjectMapper mapper = new ObjectMapper();
        SchemaFactoryWrapper visitor = new SchemaFactoryWrapper();
        mapper.acceptJsonFormatVisitor(mapper.constructType(Foo.class), visitor);
        JsonSchema schema = visitor.finalSchema();
        String schemaString = mapper.writerWithDefaultPrettyPrinter().writeValueAsString(schema);
        log.debug(schemaString);

1. Copy/paste that resulting string into a file. It seems to me (I'm not really experienced in this though) that the json at this point is correct. Here's a part of it:

        "foo" : {
            "type" : "array",
            "items" : {
                "type" : "object",
                "id" : "urn:jsonschema:com:company:project:stuff:Bar",
                "properties" : {
                    "baz" : {
                        "type" : "string"
                    }
                }
            }
        }

1. (I debug in the middle of this, and discover that secondSchema looks like its structure is missing a bunch of definitions, just has plain-looking "object" items in a lot of places).

        ObjectMapper objectMapper = new ObjectMapper();
        JsonSchema secondSchema = objectMapper.readValue(Experiment.class.getResource("/schema.json"), JsonSchema.class);
        ObjectMapper secondMapper = new ObjectMapper();
        String secondSchemaString = secondMapper.writerWithDefaultPrettyPrinter().writeValueAsString(secondSchema);
        log.debug(secondSchemaString);

1. Then I look at the secondSchemaString and compare it with the original. Here's that same section:

        "foo" : {
            "type" : "array",
            "items" : {
                "type" : "object",
            }
        }

[cowtowncoder]

Ah. This may be different from the original problem then, which was wrt to generation of schema. I wouldn't be surprised if there were issues with deserialization, as much less effort has been put there. I'll see if I can figure out the problem, regardless; schema should deserialize back without losing content.

[fkrauthan]

Any news on this problem? I run into the same issue if it try to parse a ArraySchema all getItems() property fields are null. I am using version 2.6.1

[dazraf]

Hi, any progress with this? It's a notable gap in functionality.

[cowtowncoder]

@dazraf This modules does not have maintainer, and unless someone steps up it will probably be dropped from FasterXML repo for 3.0. There are better generators out there.

But if anyone wants to do a PR I can help merge.