Description

After applying the fix for issue #1624 (PR #1625), the attached schema results in incorrect code generation for the "java" generator, although I suspect other generators would suffer from the same fate.
Prior to applying the fix for #1624, the generator throws an NPE :)

The crux of the problem is that the java generator will generate the "Message" class as expected, with the "context" field being declared as a "Context" object. Unfortunately, the Context model is not generated because it is apparently considered to be a top-level map.

One might think that a possible solution would be to generate the Message.context field so that it is of type Map<String, Object> since the Context model is optimized away after being interpreted as a top-level map. But in my opinion, since Context is a referenced schema, we should not be optimizing that away. It is a distinct model defined in the apispec as an object that can have arbitrary properties set on it and is referenced from a schema property belonging to the Message schema. Therefore, it should be rendered as such... i.e. we should generate a class called Context which is a subclass of Map<String, Object>. At the very least, there should probably be a configuration property that can enable/disable the feature introduced by issue #1296.

I could see this schema flattening being done if the Message.context schema property's schema was an inline schema, but not in the case where Message.context's schema is a reference to another named schema.

openapi-generator version

master (latest)

OpenAPI declaration file content or url

Here's the apispec which exhibits the problem:
testcase.zip

Command line used for generation

Using latest master code + fix for issue #1624:

java -jar <location-of-jar>/openapi-generator-cli.jar generate -i testcase.json -g java -o ./java/testcase

Steps to reproduce

1. Process the apispec using the command above
2. Observe the emitted Message.java class; the "context" field is of type Context, but the Context model did not get generated.
   Note: if the fix for NPE in ModelUtils.isFreeFormObject #1624 is not applied, then the result will be an NPE

Related issues/PRs

#1296

Suggest a fix/enhancement

Either revert the changes in #1296 or support a configuration property that can disable that feature.