[MockMvc] [OpenAPI 3.0] usage of allOf for inheritance is not supported

[Illia Sorokoumov]

The approach for inheritance between data models described here: https://swagger.io/docs/specification/data-models/inheritance-and-polymorphism/ seems to be not supported by the library. (I had essentially to duplicate the base model fields to work around this issue).

Here are a few redacted parts of the messages I'm getting when trying to use allOf:

"message" : "[Path '/data'] Object instance has properties which are not allowed by the schema: [\"redactedProperty1\",\"redactedProperty2\"...]"

"message" : "[Path '/data'] Instance failed to match all required schemas (matched only 1 out of 2)",
    "additionalInfo" : [ "/components/schemas/RedactedModel/allOf/0: Object instance has properties which are not allowed by the schema: [\"redactedProperty1OfExtendedModel\",\"redactedProperty2OfExtendedModel\"...]" ],

It looks like in this case the matcher is trying to make sure that the payload matches both models separately.

[James Navin]

Hi Illia,

This looks like a known issue with the interaction of allOf, anyOf etc. with the additionalProperties validation. Please take a look at the FAQ in the docs folder and see if the instructions there help.

If you still have issues let me know and I'll look into it further.

[Illia Sorokoumov]

Yeah, if I add .withLevelResolve(LevelResolverFactory.withAdditionalPropertiesIgnored()) the problem goes away, but then the validator stops complaining about unknown fields which is quite useful when the serialization framework is using a wrong name for the field for whatever reason.

[Illia Sorokoumov]

So, for the time being I've decided to go with withAdditionalPropertiesIgnored workaround and add more of required everywhere to make sure the validator is going to notice if the object mapper got the name of the field wrong, but it would be nice to have a solution that would not involve compromising the strictness of the validator.

[James Navin]

I agree - it would be ideal to have additional properties validation work with allOf composition. Unfortunately there are some fundamental reasons why its not a straight-forward thing to achieve. There is a good discussion of the problems in https://stackoverflow.com/questions/22689900/json-schema-allof-with-additionalproperties from the author of the JSON Schema spec.

I have been toying with the idea of combining all of the schemas together with allOf is used, which would allow for additional properties validation. My concern there is that it is changing the structure of the spec and so could lead to confusing validation messages where the context in the validation does not match the spec.

[Ramia SAIDAWI]

So this is still an issue , and i have to rewrite my spec

i am using minProperties/maxProperties and i have to set additionalProperties to false for it to work