Here’s the latest WebSphere Liberty beta and WebSphere Developer Tools (WDT).

Thanks to your support for our regular beta programme, we are able to release new Liberty features every few months. Most recently, in June.

Look out for more betas over the coming months.

Get it now! Ask a question about the beta

What’s in the WebSphere Liberty beta for June?

OpenAPI v3 feature

This is a new feature which starts to implement the official OpenAPI 3.0 specification. This specification is the next version of the popular Swagger v2 documentation, and has included many enhancements that REST API developers have been asking for, such as the support for callbacks, multiple server locations and a broader set of JSON schema components.

Now you can use pre-generated Swagger v2 or OpenAPI v3 documents (swagger.yaml/swagger.json and openapi.yaml/openapi.json respectively) inside their module’s META-INF, or use the new OpenAPI v3 programming model interface, io.swagger.oas.web.OpenAPIController.

To use this feature, users can provide a file called openapi.yaml (or openapi.yml/openapi.json) with their OAS document inside their web module’s META-INF folder. Here’s an example:

openapi: "3.0.0"
  version: 1.0.0
  title: Sample API
  description: A simple sample of an OpenAPI v3 document
    name: Liberty API Team
    name: Apache 2
      description: |
        Returns all pets from the system that the user has access to
      operationId: findPets
        - name: tags
          in: query
          description: tags to filter by
          required: false
          style: SIMPLE
            type: array
              type: string
        - name: limit
          in: query
          description: maximum number of results to return
          required: false
            type: integer
            format: int32
          description: unexpected error
                $ref: '#/components/schemas/Error'
      description: Returns a user based on a single ID, if the user does not have access to the pet
      operationId: find pet by id
        - name: id
          in: path
          description: ID of pet to fetch
          required: true
            type: integer
            format: int64
        - code
        - message
          type: integer
          format: int32
          type: string

Alternatively, users may provide a file called io.swagger.oas.web.OpenAPIController inside their web module’s META-INF/services folder, which contains the qualified name of an implementation of the OpenAPIController interface. In the sample below, that would be com.example.AirlinesAPIs. Using the OpenAPIController interface users can programmatically build a complete OpenAPI v3 model (instead of creating the document using a text editor).

package com.example;

public final class AirlinesAPIs implements OpenAPIController {

   public OpenAPIConfig bootstrap() {
      OpenAPI oai = new OpenAPI().info(new Info().title("Airlines").version("1.0.0")).paths(new Paths()
         .addPathItem("/airlines",new PathItem()
            .get(new Operation()
               .description("Get the list of available airlines")
               .responses(new ApiResponses()
                  .addApiResponse("200", new ApiResponse()
                     .content(new Content()
                        .addMediaType("application/json", new MediaType()
                        .schema(new Schema().ref(
      return new OpenAPIConfig().setOpenAPI(oai);

Please see the Open API Initiative and the Open API GitHub page for more information.

JSON-B v1.0 feature

The jsonb-1.0 feature provides a preview of the JSON Binding (JSON-B) 1.0 specification interfaces, as well as the reference implementation (Eclipse Yasson).

JSON technology has proven to be a powerful tool in modern Java EE applications, especially when using a Microservices oriented architecture. Traditionally applications had to provide their own JSON binding implementations and package them in a shared library or application. With the jsonb-1.0 feature, the specification interfaces and implementation are provided out of the box, ready to be used directly by applications.

To use this feature, simply enable jsonb-1.0 in the server.xml. Please see the JSON-B page for more information.

Auditing the security infrastructure

You can use the Liberty Audit feature to report and track auditable events to ensure the integrity of your configured environment.

The Liberty Audit feature introduces an infrastructure which serves two purposes:

  • Confirming the effectiveness and integrity of the existing configuration
  • Identifying areas where improvement to the configuration may be needed

The Liberty Audit feature has the ability of capture the following auditable events:

  • Basic authentication
  • Management of the audit service
  • Form login authentication
  • Client certificate authentcation
  • Servlet runAs delegation
  • Failover to basic authentication
  • Unprotected servlet authorization
  • Servlet 3.0 APIs: login/logout/authenticate
  • JACC web authorization
  • JASPI authentication
  • Form logout
  • JACC EJB authorization
  • EJB delegation
  • SCIM operations/member management
  • Dynamic audit feature handling
  • EJB authorization

This feature provides a default implementation, the AuditFileHandler, which emits audit records to a file-based log in JSON format.

  1. Add the audit-1.0 feature to the server.xml file. Note that currently the feature requires that the appSecurity-1.0 or appSecurity-2.0 feature also be present.
  2. If you wish to customize the Audit File Handler configuraton, specify the auditFileHanlder entry for the server.
    Note that if you do not specify the auditFileHandler entry, then all of the defaults will apply, and all audit events and possible outcome types will be recorded.
	    <events name="AuditEvent_1" eventName="SECURITY_AUDIT_MGMT" outcome="SUCCESS"/>   
	    <events name="AuditEvent_2" eventName="SECURITY_AUTHN" outcome="SUCCESS"/>   

The following configuration options are supported by the Liberty Audit feature:

  • maxFiles – defines the maximum number of file-based audit logs that will be kept before the oldest log is written over. If maxFiles is not specified, the default value of 100 is used
  • maxFileSize – the maximum size, in MB, of each audit log. If maxFileSize is not specified, a default size of 20 MB is used for each audit log
  • logDirectory – the location of the audit log. If logDirectory is not specified, the location defaults to WLP_OUTPUT_DIR/serverName/logs
Audit instrumentation Audit event name
Basic authentication SECURITY_AUTHN
Management of the audit service SECURITY_AUDIT_MGMT
Form login authentication SECURITY_SESSION_LOGIN
Client certificate authentication SECURITY_AUTHN
Servlet runAs delegation SECURITY_AUTHN_DELEGATION
Failover to basic authentication SECURITY_AUTHN_FAILOVER
Unprotected servlet authorization SECURITY_AUTHZ
Servlet 3.0 APIs: login/logout/authenticate SECURITY_API_AUTHN (for login, authenticate)
JACC web authorization SECURITY_AUTHZ
SCIM operations/member management SECURITY_MEMBER_MGMT
EJB authorization SECURITY_AUTHZ

Supported outcomes: SUCCESS, FAILURE and REDIRECT (for redirected authentication calls).

Admin Center feature update

On the Dashboard of the Java Batch tool in Admin Center, the Server column has been replaced by three new columns: Server Name, User Directory, and Host.

MicroProfile Config feature

With the mpConfig-1.0 feature, you can directly use the Config APIs to retrieve configuration without the need to know where the properties are defined. The properties can be dynamically updated and then retrieved by the applications without the application restarting. The configuration can be located in multiple sources, and has a priority system. If the same property is specified in multiple config sources, the value from the config source with the highest priority will be used. The properties can be overwritten by users in different environments.

MicroProfile Fault Tolerance feature

With the mpFaultTolerance-1.0 feature, you can make the service invocation resilient via retry, fallback, timeout, circuit breaker and bulkhead functionalities. If a service invocation fails, a retry can be performed. After some retries, a fallback operation can be specified. Indefinite waiting is no longer a problem as the timeout can be specified on service invocation. Repeating timeouts are solved by the functionality of the circuit breaker. You will not need to package fault tolerance libraries into your applications any more.

What’s already in there?

The May Liberty beta included the Social Login feature, an update to the Transport Security feature, an update to the API Discovery feature and an Enhancement to the Java Batch Tool on the Admin Center.

Take a look at the previous beta announcements for a full list of stuff added since the release in June 2016:

Get it now! Ask a question on Stack Overflow

1 comment on"Beta: WebSphere Liberty and tools (June 2017)"

  1. […] is a new feature (introduced in the June beta) to implement the official OpenAPI 3.0 specification, which is now […]

Join The Discussion

Your email address will not be published. Required fields are marked *