Multiple @SecurityScheme inside a @SecuritySchemes are not present in the openapi spec

[ajeans]

Describe the bug

• I need to declare two @SecurityScheme on my REST API. Declaring either @SecurityScheme works fine (I see a "securitySchemes" node in the spec), but declaring both inside a @SecuritySchemes does not work

To Reproduce
Steps to reproduce the behavior:

• Clone repository https://github.com/ajeans/multiple-security-requirements which is the minimal reproducer
• Launch the application with ./gradlew bootRun
• Check that one declaration works fine by doing curl -s http://localhost:8080/v3/api-docs | jq ".components"

$ curl -s http://localhost:8080/v3/api-docs | jq ".components"
{
  "securitySchemes": {
    "bearerToken": {
      "type": "http",
      "scheme": "bearer",
      "bearerFormat": "JWT"
    }
  }
}

• Modify ./src/main/java/com/quicksign/springdoc/security/multiplesecurityrequirements/OpenApiConfiguration.java (comment the single security declaration, uncomment the multiple security declaration), and restart the application
• Check that two declarations don't work by doing curl -s http://localhost:8080/v3/api-docs | jq ".components"

$ curl -s http://localhost:8080/v3/api-docs | jq ".components"
{}

• What version of spring-boot you are using? 2.4.4
• What modules and versions of springdoc-openapi are you using? 1.5.6

Expected behavior

• I would expect both security schemes to appear in the openapi spec

$ curl -s http://localhost:8080/v3/api-docs | jq ".components"
{
  "securitySchemes": {
    "bearerToken": {
      "type": "http",
      "scheme": "bearer",
      "bearerFormat": "JWT"
    },
    "basicAuth": {
      "type": "http",
      "scheme": "basic"
    }
  }
}

Screenshots
N/A

Additional context
This seems to have been reported already with #249 which was closed as "works for me", hence the reproducer :)

[bnasslahsen]

@ajeans,

Well, in fact it's highly recommended to declare OpenAPIDefinition with a spring managed bean (for example by adding @Component annotation).

By using a spring managed bean, it works as expected!
The main reason is to improve the performance of the OpenAPI generation, so that springdoc-openapi doesn't have to scan all the class path, for classes containing this annotation.
This is explained in the documentation.

But, i agree, that what you are reporting is a bug. Even, without using spring beans, the generation should be consistent.