-
Bug
-
Resolution: Unresolved
-
Blocker
-
None
-
-
User Experience
- Have a localServicesRouterDeployment.war, defining a root level security element, e.g.:
security: # a global security requirement declaration, must match a .components.securityScheme api_key: - admins ... components: ... securitySchemes: api_key: type: apiKey name: api_key in: header ...
- Then, have a anotherLocalServicesRouterDeployment.war, defining a root level security element, with the same name, but different attributes, e.g.:
security: # a global security requirement declaration, must match a .components.securityScheme api_key: - root ... components: securitySchemes: api_key: type: apiKey name: apiKey in: cookie ...
When deploying both the applications, the resulting OpenAPI document components element holds the result of what has been defined, and at the operation level (and conflicting names are resolved):
---
components:
schemas:
...
securitySchemes:
anotherLocalServicesRouterDeploymentapi_key:
in: cookie
name: apiKey
type: apiKey
localServicesRouterDeploymentapi_key:
in: header
name: api_key
type: apiKey
...
but the root level security element is not present.
- blocks
-
WFLY-20567 MicroProfile OpenAPI subsystem does not allow multiple deployments to use the same endpoint
-
- Pull Request Sent
-
- clones
-
WFWIP-694 MicroProfile OpenAPI and multiple deployments: conflicting @SecurityScheme occurrences generate wrong OpenAPI documentation
-
- Open
-
- is cloned by
-
WFWIP-697 MicroProfile OpenAPI and multiple deployments: conflicting root level ".tags" definitions appear in the final OpenAPI document with the same name
-
- Closed
-