Class OpenApiWebService

java.lang.Object
ubic.gemma.rest.OpenApiWebService
@Service @Path("/openapi.{type:json|yaml}") public class OpenApiWebService extends Object
Serve the OpenAPI specification held by the openApi bean.

This replaces io.swagger.v3.jaxrs2.integration.resources.OpenApiResource, which used to be registered through jersey.config.server.provider.packages in web.xml. That resource re-read the spec from Swagger's own OpenApiContext instead of returning the instance OpenApiFactory decorates, and the two could diverge permanently: GenericOpenApiContext.read() caches with cacheTTL = -1 but does an unsynchronized check-then-act, so a request that landed while the factory's asynchronous build was still running produced a second OpenAPI instance and pinned it in the cache for the life of the JVM. The served document then lacked everything the factory applies after reading — the servers list built from gemma.hosturl, the FilterArg/SortArg examples and the ${...} placeholder resolution — while the Spring bean kept the decorated copy. Resolving the Future here means there is exactly one instance and nothing left to race over.

Requests that arrive before the build finishes now block on the future rather than racing it, so the first caller after a restart waits for a complete spec instead of receiving a partial one.

Author:
poirigui

  • Constructor Details

    • OpenApiWebService

      public OpenApiWebService()

  • Method Details

    • getOpenApi

      @GET @Produces({"application/json","application/yaml"}) public jakarta.ws.rs.core.Response getOpenApi(@PathParam("type") String type, @HeaderParam("Accept-Encoding") String acceptEncoding) throws com.fasterxml.jackson.core.JsonProcessingException
      Retrieve the specification as JSON or YAML, depending on the extension used in the request path.

      The payload is large (~600 kB of JSON), so it is gzipped whenever the client advertises support. Setting Content-Encoding here is what triggers Jersey's GZipEncoder: as a ContentEncoder it compresses based on that response header rather than on Accept-Encoding. The previous OpenApiGzipHeaderDecorator set the same header from a WriterInterceptor that recognised the spec by its leading {"openapi" characters, and did so unconditionally; now that the endpoint is ours, the header is set where the entity is built and only when the client asked for it.

      Throws:
      com.fasterxml.jackson.core.JsonProcessingException