• Have two different applications which define a MyPojo.class object, say in package1 and package2.
• Both package1.MyPojo and package2.MyPojo expose an id field, but package2.MyPojo also exposes a name field.
• Then have a deployment1.war, containing a PojoExampleResource class that exposes a printPojo API, which @Consumes(MediaType.APPLICATION_JSON) and declares a parameter of type package1.MyPojo, which is annotated as @RequestBodySchema(package1.MyPojo.class).
• Finally, have a deployment2.war, containing a AnotherPojoExampleResource class that exposes a printAnotherPojo API, which @Consumes(MediaType.APPLICATION_JSON) and declares a parameter of type package2.MyPojo, which is annotated as @RequestBodySchema(package2.MyPojo.class).

When deploying both the applications, specifically deployment1.war first, and then deployment2.war, the resulting OpenAPI document would contain:

components:
  schemas:
    MyPojo:
      type: object
      properties:
        id:
          type: string
        name:
          type: string
...

So package1.MyPojo is not documented.

Additionally, the documented operations would refere to the only documented schema reference, i.e.

...
  /deployment2.war/another-example/another-pojo-example:
    get:
      requestBody:
        content:
          application/json:
            schema:
              $ref: "#/components/schemas/MyPojo"
      responses:
        "200":
          description: OK
...
  /deployment1.war/example/pojo-example:
    get:
      requestBody:
        content:
          application/json:
            schema:
              $ref: "#/components/schemas/MyPojo"
      responses:
        "200":
          description: OK

A client which is generated based on such OpenAPI documentation would create wrong stubs for /deployment1.war/example/pojo-example , possibly causing unknown property errors in server side deserialization.

This, along with WFWIP-694, seems to be due to a common set of conditions in the functional code which are the cause for everything which is generated by class level annotations and that is then reflected into the global components property of the generated OpenAPI documentation to be affected by overriding issues.