• Have a deployment1.war, containing a PojoExampleResource class that is annotated with MicroProfile OpenAPI security related annotations, e.g.:

  @SecuritySchemes(value = {
          @SecurityScheme(securitySchemeName = "http_secured", type = SecuritySchemeType.HTTP, scheme = "bearer", bearerFormat = "JWT")
  })
  @SecurityRequirements(value = {
          @SecurityRequirement(name = "http_secured") })
  @Path("/examples")
  public class PojoExampleResource {
  ...
  

• Then, have a deployment2.war, containing a AnotherPojoExampleResource class is annotated with a similar @SecurityScheme, having a different type but a conflicting name, e.g.:

  @SecuritySchemes(value = {
          @SecurityScheme(securitySchemeName = "http_secured", type = SecuritySchemeType.OAUTH2)
  })
  @SecurityRequirements(value = {
          @SecurityRequirement(name = "http_secured") })
  @Path("/another-example")
  public class AnotherPojoExampleResource {
  ...
  

When deploying both the applications, specifically deployment1.war first, and then deployment2.war, the resulting OpenAPI document components global property would contain just one occurrence of the http_secured @SecurityScheme:

---
components:
  schemas:
    ...
  securitySchemes:
    http_secured:
      type: http
      scheme: bearer
      bearerFormat: JWT
...

Additionally, the documented operations would refer to the only documented @SecurityScheme occurrence, i.e.

...
   /anotherLocalServicesRouterDeployment/another-example/another-district-example:
    get:
      ...
      security:
      - http_secured: []
  /anotherLocalServicesRouterDeployment/another-example/another-pojo-example:
    get:
      ...
      security:
      - http_secured: []
...
  /localServicesRouterDeployment/info/fqdn:
    get:
      ...
      security:
      - http_secured: []
...

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

This, along with WFWIP-693, 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.