
Leading the Way: Payara Platform Community 7 Beta Now Fully Jakarta EE 11 Certified
We’re excited to announce that Payara Platform Community 7 Beta application server is now fully certified as Jakarta EE 11 […]
One of the new features in Payara Platform version 5.182 is full compatibility with MicroProfile 1.3. In this blog post, I will introduce OpenAPI 1.0, a new API in MicroProfile 1.3. This functionality is available in both Payara Server and Payara Micro in version 5.182. It’s also available in version 4.1.2.182 for Payara Support customers.
The OpenAPI specification itself is unrelated to MicroProfile. It’s a specification designed to provide a standard format for documenting REST API services. An OpenAPI document looks similar to the following:
openapi: "3.0.0" info: version: 1.0.0 title: Swagger Document servers: - url: http://test.payara.fish/v1 paths: /hello: get: summary: "Returns a hello world message." operationId: helloWorld parameters: - name: count in: query description: "How many instances of the message to return." required: false schema: type: integer responses: 200: description: "A hello world message." content: text/plain: schema: type: string 500: description: "An unexpected error." content: application/json: schema: $ref: "#/components/schemas/Error" components: schemas: Error: required: - code - message properties: code: type: integer message: type: string
This document contains things such as:
This document is extremely useful since, as it follows a standard, it can be used in a range of tools such as those provided by the Swagger suite. These let you do all sorts of things such as design, edit and test a REST API documented by an OpenAPI document.
MicroProfile designed the MicroProfile OpenAPI specification to extend the general OpenAPI specification and integrate it into MicroProfile applications. The specification states that any implementing servers should host an endpoint at /openapi
which will provide an OpenAPI document built from a deployed application. When you deploy an application, this document will be built automatically according to the application contents. The document can then be edited or used however you like. The specification also illustrates a few methods of editing this document. You could for example add a description to an endpoint, or a new title for the document so that the document hosted at the /openapi
endpoint appears in any way you like.
No configuration is needed for the OpenAPI implementation in the Payara Platform, you need just deploy an application! The OpenAPI is included in Payara Micro and Payara Server, so which one you use doesn’t matter. For a full example of the usage, see the specification documentation.
Let’s say you deployed an application with only the following classes:
import javax.ws.rs.ApplicationPath; import javax.ws.rs.core.Application; @ApplicationPath("/api") public class TestApplication extends Application { }
import javax.ws.rs.Path; import javax.ws.rs.GET; @Path("/hello") public class TracedResource { @GET public String helloWorld() { return "Hello World!"; } }
With this application deployed, visiting http://localhost:8080/openapi/ will produce the following document:
openapi: 3.0.0 info: title: Deployed Resources version: 1.0.0 servers: - url: http://localhost:8080/app description: Default Server. paths: /api/hello: get: operationId: helloWorld responses: default: description: Default Response. content: '*/*': schema: type: string components: {}
This is useful, but not as useful as it could be. Often you’ll want descriptions, and more in depth descriptors for the objects in the application (more similar to the first document in this blog). There are various ways of doing this. Each of the following configuration sources are applied in order:
OASModelReader
implementation in the application. This provides a base document to be built upon for the final output.OASFilter
implementation in the application. This will visit each element in the document and either remove it or edit it programmatically.A brief example of each can be seen below. For a more detailed example utilising each of these, see the following example: https://github.com/payara/Payara-Examples/tree/master/microprofile/openapi-example.
The MicroProfile OpenAPI specification includes a few properties for the MicroProfile Config API. These can be included from any of the sources defined in the MicroProfile Config API. For example, in a config file stored in src/main/resources/META-INF/microprofile-config.properties
.
An example configuration property might look as follows:
# Whether to disable the scanning of application classes mp.openapi.scan.disable=false
MicroProfile OpenAPI provides two interfaces for the application developer to implement:
org.eclipse.microprofile.openapi.OASFilter
org.eclipse.microprofile.openapi.OASModelReader
Each of these have a similar function, but are applied at different times. An implementation of OASModelReader
will create an initial OpenAPI document to build the final document from. An implementation of OASFilter
will be used to visit every object in the OpenAPI document before it is published. This allows final configuration changes to be made.
When implementing each of these, the relevant interface should be implemented, and a config property should be specified in the Config API (often in microprofile-config.properties
):
# Configure the processing classed defined to edit the OpenAPI document. mp.openapi.model.reader=fish.payara.examples.microprofile.openapi.ModelReader mp.openapi.filter=fish.payara.examples.microprofile.openapi.Filter
A static OpenAPI document file can be placed in src/main/resources/META-INF
and called any of openapi.yaml
, openapi.yml
or openapi.json
(and represented in the appropriate format of YAML or JSON). When this happens, this document will be used before any application processing. This means that if you want, you can take the document produced by the application initially, then remove any OpenAPI annotations present, edit the document as you wish and place it in the resources folder again to produce the same output!
MicroProfile OpenAPI defines several annotations that can be used to augment the produced OpenAPI document. These are detailed in the MicroProfile OpenAPI specification, but an example of them is as follows:
import javax.ws.rs.GET; import javax.ws.rs.Path; import org.eclipse.microprofile.openapi.annotations.Operation; @Path("/hello") public class TestResource { @GET @Operation(operationId = "hello world") public String helloWorld() { return "Hello World!"; } }
This helps make small tweaks to the produced document, and in the most non-intrusive way of editing the output.
The OpenAPI service is enabled by default in Payara Server and Payara Micro. The service can be controlled by two new asadmin commands. These need very little explanation, so here they are for reference!
set-openapi-configuration --enabled=true/false
get-openapi-configuration
When the OpenAPI service is disabled, no applications deployed during this period will have OpenAPI documents produced, and the endpoint will return a 403 response. A quirk of the service is that when it is enabled again, any applications deployed before it was disabled will still have their document shown, whereas any deployed while it was disabled will need redeploying. Outside of this functionality, the most recently deployed application will have it’s OpenAPI document shown.
The new MicroProfile Open API service in Payara Platform enables building and serving OpenAPI documents out of the box. Before the OpenAPI implementation, documents would have to be produced manually, or using an external tool and hosted as part of the application. This new integration eases the production of the document, and makes it feel more native to a MicroProfile application.
{{cta(‘4c7626f5-1e53-418e-90c8-add6e4af19c9’)}}
Share:
We’re excited to announce that Payara Platform Community 7 Beta application server is now fully certified as Jakarta EE 11 […]
Managing Payara Server Just Got Smarter Imagine managing your Jakarta EE applications not just with Maven goals, but by […]
Welcome aboard the August 2025 issue of The Payara Monthly Catch! With summer in full swing, things may have felt […]
Payara will have a UI as Open Liberty has: localhost:8181/openapi/ui ?
thanks .
Hi Daniel,
Unfortunately it’s not planned yet, although I’ll raise it as an idea.
Kind regards,
Matt
Thanks for the article. If there is no UI, it would be useful to explain what can be done with the openapi document, once you have it.
Hi Martin,
The blog mentions towards the start that since the OpenAPI is a standard, the document is usable in, for example, all the Swagger suite of tools. The Swagger UI for example, can be deployed along with your application, taking the OpenAPI document as an input. The OpenAPI document itself is just a standard format document that should be readable by any relevant tool or by anyone who wants to use the REST API being documented.
Hope this helps.
Kind regards,
Matt
Matt, thanks for the article. I’m having some problems getting this to work as my Resource operation is in a project module. Our ear deployment several war modules and one EJB module. The @Operation annotation is in a class inside our API war module. Here’s what I have on my configuration:
-Dmp.openapi.servers=http://localhost:8080/company/api
-Dmp.openapi.scan.packages=com.company.api.routes
The result is the following:
openapi: 3.0.0
info:
title: Deployed Resources
version: 1.0.0
servers:
– url: http://localhost:8080/company/api
paths: {}
components: {}
No components seem to show up even though I specify to scan that package.
Would appreciate your input/help. Thanks!
Hi Brant,
The MicroProfile specification itself doesn’t support EARs as a deployment method. Because of this, applications inside EARs will most likely not be processed by the OpenAPI implementation. It may be possible however to add this support in the future. I would recommend creating a GitHub issue to add support for WARs inside EARs.
Hope this helps,
Matt
Hi,
in our project we have a problem with the generation of the Swagger UI when using inheritance:
@Schema(name = “Test1”, description = “Test1”)
public class Test1{
@Schema(description = “test1field”, example = “test1field”)
public String test1Field;
public String getTest1Field() {
return test1Field;
}
public void setTest1Field(String test1field) {
this.test1Field = test1field;
}
}
@Schema(name = “Test2”, description = “Test 2 Description.”)
public class Test2 extends Test1{
@Schema(description = “Test2 field”, example = “field”)
private String test2Field;
public String getTest2Field() {
return test2Field;
}
public void setTest2Field(String test2Field) {
this.test2Field = test2Field;
}
}
The problem is that the generated yaml under http://localhost:8080/openapi does not display the properties of the parent class and therefore they are also not included in the child class.
Test1:
description: Test1
Test2:
properties:
test2Field:
type: string
description: Test2 field
example: field
description: Test 2 Description.
allOf:
– $ref: ‘#/components/schemas/Test1’
Is there a way to fix this?
Hi Neven,
If you speak to the internal BMW person who is responsible for raising tickets, as a customer you will be able to raise your issue through there for a speedy response. Otherwise please create a Github issue. An initial guess is that the OpenAPI rewrite may solve it.