Why require OpenAPI processing for a non-JAX-RS/Spring deployment?

[pferraro]

The following TCK tests:

• ModelConstructionTest
• OASFactoryErrorTest
• StaticDocumentTest

... use web application archives that do not contain any JAX-RS nor Spring applications. Why should an implementation of MicroProfile OpenAPI be required to perform any OpenAPI processing for such a deployment?

[EricWittmann]

I think because it is possible to disable annotation scanning. Annotation scanning is useful primarily when doing code-first API development. However, the spec also covers alternative use-cases. The static document processing support (for example) covers the Design-First approach to API development. In that case you would design an API (for example using https://studio.apicur.io ) and then implement it using JAX-RS, but configure MP-OpenAPI to include the API design in the deployment and disable annotation scanning.

I suppose the TCK could be made more realistic by actually including some JAX-RS resources in the deployments but configure them to disable scanning.

Those tests are designed to specifically test the non-annotation scanning functionality of the specification.

[kenfinnigan]

From the perspective that MicroProfile will always have JAX-RS present, it's probably more accurate for the tests to include JAX-RS Applications but disable scanning.

[jmini]

There is an interesting approach done by the SmallRye OpenAPI project:

Since version 2.0.0, they started to introduce support Microprofile OpenAPI on top of Spring. So in this case you do not have JaxRS.

[pferraro]

Since version 2.0.0, they started to introduce support Microprofile OpenAPI on top of Spring. So in this case you do not have JaxRS.

AFAICT, there is no TCK coverage for Spring applications. The problematic tests mentioned in my first comment are neither JAX-RS nor Spring applications. Thus, the issue still remains, i.e. in order to pass the TCK, a container must include OpenAPI processing for all WARs, not just JAX-RS (or Spring) applications.

[MikeEdgar]

@pferraro, we discussed this topic in today's OpenAPI call. Do you still view this as an issue in the TCK? Did it cause a problem or is it more of an observation/question?

[pferraro]

@MikeEdgar The side effect of these TCK tests (i.e. those that use an "empty" test application without any JAX-RS endpoints) is that a container must expose an OpenAPI endpoint for every web application, even those that use neither JAX-RS nor Spring, otherwise the container will not pass the MicroProfile OpenAPI TCK. This does not make sense to me.

[MikeEdgar]

We briefly discussed this issue in a recent team call and the suggestion is to update the spec and TCK to indicate that an OpenAPI deployment (i.e. hosting of endpoint /openapi) is only required when one or more of the following is true for a deployment/application:

• An OASModelReader has been configured with mp.openapi.model.reader
• An OASFilter has been configured with mp.openapi.filter
• One of the allowed static files is present, i.e. META-INF/openapi.(json|yaml)
• The application uses JAX-RS

If there are no disagreements with the approach, this can be marked for inclusion in the 3.1 release.