Open Liberty

SpringBoot 4.0, preview of Jakarta Data 1.1 and more in 25.0.0.12-beta

Tue, 18 Nov 2025 00:00:00 +0000

This beta release adds Spring Boot 4.x support, previews Jakarta Data 1.1 capabilities, and enhances the Netty-based HTTP transport. It also updates Model Context Protocol Server 1.0 and introduces the option to use your own AES-256 key for Liberty password encryption.

The Open Liberty 25.0.0.12-beta includes the following beta features (along with all GA features):

SpringBoot 4.0
Early preview of Jakarta Data 1.1
Model Context Protocol Server 1.0 updates
Updates to Netty‑based HTTP transport on Open Liberty
Bring your own AES-256 Key

SpringBoot 4.0

Open Liberty currently supports running Spring Boot 1.5, 2.x, and 3.x applications. With the introduction of the new springBoot-4.0 feature, users can now deploy Spring Boot 4.x applications by enabling this feature. While Liberty consistently supports Spring Boot applications packaged as WAR files, this enhancement extends support to both JAR and WAR formats for Spring Boot 4.x applications.

The springBoot-4.0 feature provides complete support for running a Sprint Boot 4.x application on Open Liberty as well as having the capability to thin the application when creating applications in containers.

To use this feature, the user must be running Java 17 or later with EE11 features enabled. If the application uses servlets, it must be configured to use Servlet 6.1. Include the following features in your server.xml file to define the settings.

<features>
   <feature>springboot-4.0</feature>
   <feature>servlet-6.1</feature>
</features>

The server.xml configuration for deploying a Spring Boot application follows the same approach as in earlier Liberty Spring Boot versions.

<springBootApplication id="spring-boot-app" location="spring-boot-app-0.1.0.jar" name="spring-boot-app" />

As in earlier versions, the Spring Boot application JAR can be deployed by placing it in the /dropins/spring folder. The springBootApplication configuration in the server.xml file can be omitted when using this deployment method.

Early preview of Jakarta Data 1.1

This release previews three new features of Jakarta Data 1.1: retrieving a subset or projection of entity attributes, the @Is annotation, and Constraint subtype parameters for repository methods that apply basic constraints to repository @Find and @Delete operations.

Previously, repository methods couldn’t limit retrieval of results to subsets of entity attributes (commonly referred to as projections). Now, repository methods can return Java records that represent a subset of an entity. In addition, parameter-based @Find and @Delete methods earlier were not able to filter on conditions other than equality. Now, more advanced filtering can be done in two different ways: typing the repository method parameter with a Constraint subtype or indicating the Constraint subtype by using the @Is annotation.

In Jakarta Data, you write simple Java objects called Entities to represent data, and you write interfaces called Repositories to define operations on data. You inject a Repository into your application and use it. The implementation of the Repository is automatically provided for you!

Start by defining an entity class that corresponds to your data. With relational databases, the entity class corresponds to a database table and the entity properties (public methods and fields of the entity class) generally correspond to the columns of the table. An entity class can be:

annotated with jakarta.persistence.Entity and related annotations from Jakarta Persistence
a Java class without entity annotations, in which case the primary key is inferred from an entity property named id or ending with Id and an entity property named version designates an automatically incremented version column.

Here’s a simple entity,

@Entity
public class Product {
    @Id
    public long id;
    public String name;
    public float price;
    public float weight;
}

After you define the entity to represent the data, it is usually helpful to have your IDE generate a static metamodel class for it. By convention, static metamodel classes begin with the underscore character, followed by the entity name. Because this beta is being made available well before the release of Jakarta Data 1.1, we cannot expect IDEs to generate for us yet. However, we can provide the static metamodel class that an IDE would be expected to generate for the Product entity:

@StaticMetamodel(Product.class)
public interface _Product {
    String ID = "id";
    String NAME = "name";
    String PRICE = "price";
    String WEIGHT = "weight";

    NumericAttribute<Product, Long> id = NumericAttribute.of(
            Product.class, ID, long.class);
    TextAttribute<Product> name = TextAttribute.of(
            Product.class, NAME);
    NumericAttribute<Product, Float> price = NumericAttribute.of(
            Product.class, PRICE, float.class);
    NumericAttribute<Product, Float> weight = NumericAttribute.of(
            Product.class, WEIGHT, float.class);
}

The first half of the static metamodel class includes constants for each of the entity attribute names so that you don’t need to otherwise hardcode string values into your application. The second half of the static metamodel class provides a special instance for each entity attribute, from which you can build restrictions and sorting to apply to queries at run time.

The following example is a repository that defines operations that are related to the Product entity. Your repository interface can inherit from built-in interfaces such as BasicRepository and CrudRepository. These interfaces contain various general-purpose repository methods for inserting, updating, deleting, and querying for entities. In addition, you can compose your own operations using the static metamodel and annotations such as @Find or @Delete.

@Repository(dataStore = "java:app/jdbc/my-example-data")
public interface Products extends CrudRepository<Product, Long> {

    // Retrieving the whole entity,
    @Find
    Optional<Product> find(@By(_Product.ID) long productNum);

    // The Select annotation can identify a single entity attribute to retrieve,
    @Find
    @Select(_Product.PRICE)
    Optional<Float> getPrice(@By(_Product.ID) long productNum);

    // You can return multiple entity attributes as a Java record,
    @Find
    @Select(_Product.WEIGHT)
    @Select(_Product.NAME)
    Optional<WeightInfo> getWeightAndName(@By(_Product.ID) long productNum);

    static record WeightInfo(float itemWeight, String itemName) {}

    // The Select annotation can be omitted if the record component names match the entity attribute names,
    @Find
    List<WeightPriceInfo> getWeightAndPrice(@By(_Product.Name) String name);

    static record WeightPriceInfo(float weight, float price) {}

    // Constraint subtypes (such as Like) for method parameters offer different types of filtering,
    @Find
    Page<Product> named(@By(_Product.Name) Like namePattern,
                        Order<Product> sorting,
                        PageRequest pageRequest);

    // The @Is annotation also allows you to specify Constraint subtypes,
    @Find
    @OrderBy(_Product.PRICE)
    @OrderBy(_Product.NAME)
    List<Product> pricedBelow(@By(_Product.PRICE) @Is(LessThan.class) float maxPrice,
                              @By(_Product.Name) @Is(Like.class) String namePattern);

    @Delete
    long removeHeaviest(@By(_Product.WEIGHT) @Is(GreaterThan.class) float maxWeightAllowed);
}

See the following example of the application that uses the repository and static metamodel.

@DataSourceDefinition(name = "java:app/jdbc/my-example-data",
                      className = "org.postgresql.xa.PGXADataSource",
                      databaseName = "ExampleDB",
                      serverName = "localhost",
                      portNumber = 5432,
                      user = "${example.database.user}",
                      password = "${example.database.password}")
public class MyServlet extends HttpServlet {
    @Inject
    Products products;

    protected void doGet(HttpServletRequest req, HttpServletResponse resp)
            throws ServletException, IOException {
        // Insert:
        Product prod = ...
        prod = products.insert(prod);

        // Find one entity attribute:
        price = products.getPrice(prod.id).orElseThrow();

        // Find multiple entity attributes as a Java record:
        WeightInfo info = products.getWeightAndName(prod.id);
        System.out.println(info.itemName() + " weighs " + info.itemWeight() + " kg.");

        // Filter by supplying a Like constraint, returning only the first 10 results:
        Page<Product> page1 = products.named(
                        Like.pattern("%computer%"),
                        Order.by(_Product.price.desc(),
                                 _Product.name.asc(),
                                 _Product.id.asc()),
                        PageRequest.ofSize(10));

        // Filter by supplying values only:
        List<Product> found = pricedBelow(50.0f, "%keyboard%");

        ...
    }
}

For more information about Jakarta Data 1.1, see the following resources:

Note This beta includes only the Data 1.1 features for entity subsets or projections, the @Is annotation, and Constraint subtypes as repository method parameters that accept basic constraint values. Other new Data 1.1 features are not included in this beta.

Model Context Protocol Server 1.0 updates

The Model Context Protocol (MCP) is an open standard for AI applications to access real-time information from external sources. The Liberty MCP Server feature mcpServer-1.0 allows developers to expose the business logic of their applications, allowing it to be integrated into agentic AI workflows.

This beta release of Liberty includes important updates to the mcpServer-1.0 feature, including session management and easier discovery of the MCP endpoint.

Prerequisites

To use the mcpServer-1.0 feature, it is required to have Java 17 installed on your system.

MCP Session Management

This beta version includes support for the session management function of the MCP specification. This feature enables stateful sessions between client and server, allowing the server to securely correlate multiple requests in the same session for features like tool call cancellation.

When a client connects to the MCP server, a unique session ID is assigned to the client during the initialization phase and returned in the Mcp-Session-Id HTTP response header. For subsequent requests, the client must include the session ID in the Mcp-Session-Id request header.

MCP Endpoint Discoverability

The MCP endpoint is made available at /mcp under the context root of your application, e.g., http://localhost:9080/myMcpApp/mcp. For ease of discovery, the URL of the MCP endpoint for your Liberty hosted application is now output to the server logs on application startup.

The following example shows what you would see in your logs if you have an application called myMcpApp:

I MCP server endpoint: http://localhost:9080/myMcpApp/mcp

In this beta version, the MCP server endpoint is also accessible with a trailing slash(/) at the end, for example, http://localhost:9080/myMcpApp/mcp/.

Liberty MCP Server API Documentation

You can now find API documentation for the Liberty MCP Server feature. The javadoc is located in the io.openliberty.mcp_1.0-javadoc.zip file within your wlp/dev/api/ibm/javadoc directory.

Attach the Liberty MCP Server feature’s Javadoc to your IDE to view descriptions of the API’s methods and class details.

Note: The following packages and interfaces that are documented in the Javadoc are not yet implemented:

io.openliberty.mcp.encoders
io.openliberty.mcp.annotations.OutputSchemaGenerator
io.openliberty.mcp.annotations.Tool.OutputSchema

For more information about Liberty MCP Server feature mcpServer-1.0, including how to get started with it, see the blog post.

Updates to Netty‑based HTTP transport on Open Liberty

Open Liberty intoduced Netty-based HTTP transport for 25.0.0.11-beta preview. This change replaced the underlying transport implementation for HTTP/1.1, HTTP/2, WebSocket, JMS, and SIP communications. In this beta release, there are some updates added to this feature. It is designed for zero migration impact—your applications and the server.xml file continue to behave as before. We are looking forward and counting on your feedback before GA!

Netty’s event‑driven I/O gives us a modern foundation for long‑term scalability, easier maintenance, and future performance work, all without changing APIs or configuration!

No changes are required to effectively use the current 'All Beta Features' runtime for this release. To help us evaluate parity and performance with real-world scenarios, you can try the following things:

HTTP/1.1 and HTTP/2: large uploads or downloads, chunked transfers, compression-enabled content, keep-alive behavior.
WebSocket: long-lived communications, backpressure scenarios
Timeouts: read/write/keep-alive timeouts under load
Access logging: verify formatting and log results compared to previous builds
JMS communications: message send/receive throughput, durable subscriptions

Limitations of the Beta release:

HTTP

HTTP requests with content length greater than the maximum integer value fails due to internal limitations on request size with Netty.
When the HTTP option maxKeepAliveRequests has no limit, HTTP 1.1 limits pipelined requests to 50.
HTTP option resetFramesWindow is reduced from millisecond to second precision due to limitations in the Netty library.
Due to internal limitations of the Netty library, the HTTP option MessageSizeLimit is now adjusted to be capped at the maximum integer value for HTTP/2.0 connections.
Due to internal differences with Netty, the HTTP option ThrowIOEForInboundConnections could behave differently from the Channel Framework implementation.
Due to internal limitations of Netty, acceptThread and waitToAccept TCP options are currently not implemented and are ignored for the current Beta if set.
Cleartext upgrade requests for HTTP 2.0 with request data are rejected with a 'Request Entity Too Large' status code. A fix is in progress.

WebSocket

Websocket inbound requests can generate FFDC RuntimeExceptions on connection cleanup when a connection is closed from the client side.

SIP

SIP Resolver transport does not use a Netty transport implementation until this release. This issue is resolved in the current beta!

ALPN

Currently, our Netty implementation supports only the native JDK ALPN implementation. Additional information for the ALPN implementations that are currently supported by the Channel Framework but not our Netty beta can be found here

Bring Your Own AES-256 Key

Liberty now allows you to provide a Base64-encoded 256-bit AES key for password encryption.

What’s New?

Previously, Liberty supported the wlp.password.encryption.key property, which accepted a password and derived an AES key through a computationally intensive process. This derivation involved repeated hashing with a salt over many iterations, which added overhead during server startup.

Now you can now supply a pre-generated AES key directly. This eliminates the derivation step, resulting in faster startup times and improved runtime performance when encrypting and decrypting passwords.

Why It Matters

This feature not only improves performance but also prepares for migration from traditional WebSphere. The encoded password format remains the same, and future migration tools will allow you to export keys from traditional WebSphere for use in Liberty.

How to Enable It

Obtain a 256-bit AES key - Generate a 256-bit AES key using your own infrastructure and encode it in Base64, or by using securityUtility.

To generate a 256-bit AES key using securityUtility, run the new securityUtility generateAESKey task to:
- Generate a random AES key:
  ./securityUtility generateAESKey
- Derive a key from a passphrase:
  ./securityUtility generateAESKey --key=<password>
Configure the key in Liberty

Add the following variable in server.xml or an included file:
```
<variable name="wlp.aes.encryption.key" value="<your_aes_key>" />
```
Encode your passwords

Use securityUtility encode with one of these options:
- Provide the key directly:
  ./securityUtility encode --encoding=aes --base64Key=<your_base64_key> <password>
- Specify an XML or properties file containing wlp.aes.encryption.key or wlp.password.encryption.key. Note: The aesConfigFile parameter now allows users to encode with either of the aes properties:
  ./securityUtility encode --encoding=aes --aesConfigFile=<xml_or_properties_file_path> <password>
Update configuration

Copy the new encoded values into your server configuration.

Performance Tip: For best results, re-encode all passwords using the new key. Mixed usage of old and new formats is supported for backward compatibility, but full migration ensures optimal performance.

Other command line tasks have been updated to accept Base64 keys and AES configuration files in a similar fashion:

securityUtility
- createSSLCertificate
- createLTPAKeys
- encode
configUtility
- install
collective
- create
- join
- replicate

Try it now

To try out these features, update your build tools to pull the Open Liberty All Beta Features package instead of the main release. The beta works with Java SE 25, Java SE 21, Java SE 17, Java SE 11, and Java SE 8.

If you’re using Maven, you can install the All Beta Features package using:

<plugin>
    <groupId>io.openliberty.tools</groupId>
    <artifactId>liberty-maven-plugin</artifactId>
    <version>3.11.5</version>
    <configuration>
        <runtimeArtifact>
          <groupId>io.openliberty.beta</groupId>
          <artifactId>openliberty-runtime</artifactId>
          <version>25.0.0.12-beta</version>
          <type>zip</type>
        </runtimeArtifact>
    </configuration>
</plugin>

You must also add dependencies to your pom.xml file for the beta version of the APIs that are associated with the beta features that you want to try. For example, the following block adds dependencies for two example beta APIs:

<dependency>
    <groupId>org.example.spec</groupId>
    <artifactId>exampleApi</artifactId>
    <version>7.0</version>
    <type>pom</type>
    <scope>provided</scope>
</dependency>
<dependency>
    <groupId>example.platform</groupId>
    <artifactId>example.example-api</artifactId>
    <version>11.0.0</version>
    <scope>provided</scope>
</dependency>

Or for Gradle:

buildscript {
    repositories {
        mavenCentral()
    }
    dependencies {
        classpath 'io.openliberty.tools:liberty-gradle-plugin:3.9.5'
    }
}
apply plugin: 'liberty'
dependencies {
    libertyRuntime group: 'io.openliberty.beta', name: 'openliberty-runtime', version: '[25.0.0.12-beta,)'
}

Or if you’re using container images:

FROM icr.io/appcafe/open-liberty:beta

Or take a look at our Downloads page.

If you’re using IntelliJ IDEA, Visual Studio Code or Eclipse IDE, you can also take advantage of our open source Liberty developer tools to enable effective development, testing, debugging and application management all from within your IDE.

For more information on using a beta release, refer to the Installing Open Liberty beta releases documentation.

We welcome your feedback

Let us know what you think on our mailing list. If you hit a problem, post a question on StackOverflow. If you hit a bug, please raise an issue.

Enhanced message validation for XML Web Services in 24.0.0.12-beta

Tue, 19 Nov 2024 00:00:00 +0000

The 24.0.0.12-beta release enhances inbound SOAP message validation in XML Web Services to simplify message debugging and make your web services and clients more resilient.

Fine-tuning XML Web Services inbound SOAP message validation

Open Liberty’s XML Web Services features now support fine-grained message validation for inbound SOAP messages. This enhancement provides more control over message validation options. In Open Liberty 24.0.0.12-beta, you can configure message validation using new attributes in the server.xml file. These attributes are available for the webService and webServiceClient elements.

Attribute Description

Attribute	Description
`enableSchemaValidation`	Enable full validation against the XML schema
`enableDefaultValidation`	Enable or disable default validation for JAXB
`ignoreUnexpectedElements`	Use default validation while ignoring `UnmarshallExceptions: Unknown Element` errors

enableSchemaValidation

Enable full validation against the XML schema

enableDefaultValidation

Enable or disable default validation for JAXB

ignoreUnexpectedElements

Use default validation while ignoring UnmarshallExceptions: Unknown Element errors

The default value for enableDefaultValidation in the webServiceClient element is true. The rest of the attributes default to false in both the webServiceClient and webService elements.

These attributes require one of the following XML Web Services features to be enabled in your server.xml file:

Jakarta XML Web Services 4.0 (xmlWS-4.0)
Jakarta XML Web Services 4.0 (xmlWS-3.0)
Java Web Services 2.2 (jaxws-2.2)

By using these attributes, you can tailor message validation to your specific needs and improve the security and reliability of your SOAP-based web services. You can apply the configuration to web services (webService) or web service clients (webServiceClient), either globally, or to an individual client or web service implementation.

XML schema validation

You can set the enableSchemaValidation=true attribute to provide more insight into JAXB unmarshalling exceptions and make painful message debugging easier. This option is the highest level of XML validation, which provides faster debugging and the most thorough checks on inbound message contents. But it comes with a tradeoff: higher performance cost.

Global XML schema validation

The following example shows how to enable XML schema validation for web services globally for your Open Liberty runtime:

<webService enableSchemaValidation="true" />

To enable XML schema validation globally for web service clients, set the same attribute on the webServiceClient element:

<webServiceClient enableSchemaValidation="true" />

Targeted XML schema validation

The following example shows how to enable XML schema validation for a particular web service by using the web service port:

<webService portName="<web service port name>"  enableSchemaValidation="true" />

The value of portName is the port name of the Web Service implementation you’re configuring. This name comes from your @WebService(portName=<web service port name> annotated class. Alternatively, you can check the <wsdl:port … name="Web Service Port Name"> line in your WSDL file for the port name.

The following example shows how to enable XML schema validation for a specific client service:

<webServiceClient serviceName="<client service name>"  enableSchemaValidation="true" />

The value of serviceName is the name of the Web Service Client you’re configuring. This name comes from your @WebServiceClient(serviceName=<client service name> annotated stub class for managed clients. For unmanaged clients, you can check the <wsdl:service name="<client service name>" line in your WSDL file.

Default validation

You can configure the default level of JAXB validation of inbound SOAP Messages with the enableDefaultValidation=true attribute. Default validation is much more efficient than XML schema validation, so enabling it provides basic message validation with lower overhead. Disabling it lets you ignore various unmarshalling errors for problematic messages. Default validation is enabled by default for web services, but disabled for web service clients.

Global default validation

The following example shows how to enable default validation globally for web services in your Open Liberty runtime:

<webService enableDefaultValidation="true"/>

Default validation is enabled by default for web service clients. To disable default validation globally for web service clients, set the enableDefaultValidation="false" attribute on the webServiceClient element.

<webServiceClient enableDefaultValidation="false"/>

Targeted default validation

The following example shows how to enable default validation for a specific web service:

<webService  portName="SayHelloService" enableDefaultValidation="true"/>

Default validation is enabled by default for web service clients. To disable default validation for a specific web service client, set the enableDefaultValidation="false" attribute on the webServiceClient element and use the serviceName attribute to specify the client service.

<webServiceClient serviceName="<client service name>"  enableDefaultValidation="false" />

Ignore unexpected elements

Inbound SOAP messages often contain extra elements in the SOAP body when a web service is updated but the client is not. When a message contains an unknown element, Open Liberty throws a UnmarshallingException: Unknown Element. By enabling ignoreUnexpectedElements, you can keep validation enabled while ignoring unknown elements.

Global configuration

The following example shows how to ignore unexpected elements globally for web services on your Open Liberty runtime:

<webService  ignoreUnexpectedElements="true"/>

To ignore unexpected elements globally for web service clients, set the ignoreUnexpectedElements attribute on the webServiceClient element.

Targeted configuration

The following example shows how to ignore unexpected elements for a specific web service:

<webService  portName="SayHelloService" ignoreUnexpectedElements="true"/>

To ignore unexpected elements for a specific web service client, set the same attribute on the webServiceClient element and use the serviceName attribute to specify the client service.

Try it now

To try out these features, update your build tools to pull the Open Liberty All Beta Features package instead of the main release. The beta works with Java SE 23, 21, 17, 11, and 8.

If you’re using Maven, you can install the All Beta Features package by using:

<plugin>
    <groupId>io.openliberty.tools</groupId>
    <artifactId>liberty-maven-plugin</artifactId>
    <version>3.11.1</version>
    <configuration>
        <runtimeArtifact>
          <groupId>io.openliberty.beta</groupId>
          <artifactId>openliberty-runtime</artifactId>
          <version>24.0.0.12-beta</version>
          <type>zip</type>
        </runtimeArtifact>
    </configuration>
</plugin>

You must also add dependencies to your pom.xml file for the beta version of the APIs that are associated with the beta features that you want to try. For example, the following block adds dependencies for two example beta APIs:

<dependency>
    <groupId>org.example.spec</groupId>
    <artifactId>exampleApi</artifactId>
    <version>7.0</version>
    <type>pom</type>
    <scope>provided</scope>
</dependency>
<dependency>
    <groupId>example.platform</groupId>
    <artifactId>example.example-api</artifactId>
    <version>11.0.0</version>
    <scope>provided</scope>
</dependency>

Or for Gradle:

buildscript {
    repositories {
        mavenCentral()
    }
    dependencies {
        classpath 'io.openliberty.tools:liberty-gradle-plugin:3.9.1'
    }
}
apply plugin: 'liberty'
dependencies {
    libertyRuntime group: 'io.openliberty.beta', name: 'openliberty-runtime', version: '[24.0.0.12-beta,)'
}

Or if you’re using container images:

FROM icr.io/appcafe/open-liberty:beta

Or take a look at our Downloads page.

If you’re using IntelliJ IDEA, Visual Studio Code or Eclipse IDE, you can also take advantage of our open source Liberty developer tools to enable effective development, testing, debugging, and application management all from within your IDE.

For more information on using a beta release, refer to the Installing Open Liberty beta releases documentation.

We welcome your feedback

Let us know what you think on our mailing list. If you hit a problem, post a question on StackOverflow. If you hit a bug, please raise an issue.

Rethinking microservices

Tue, 12 Nov 2024 00:00:00 +0000

There are many misconceptions for microservices, which have been around for over a decade. Some people wonder whether microservices are going to die, especially in an IT industry that is quickly moving toward the cloud. With serverless becoming a hot topic, will microservices survive in the serverless era?

In this blog, take a step back and rethink microservices. We start with the history of microservices, then misconception about microservices, best practices of microservices and finally the future of microservices.

Simplify your configuration with versionless features in 24.0.0.8

Tue, 13 Aug 2024 00:00:00 +0000

This release introduces versionless features for the Jakarta EE, Java EE, and MicroProfile platforms. It also includes updates to eliminate unnecessary audit records.

In Open Liberty 24.0.0.8:

Streamline feature selection with versionless Jakarta EE, Java EE, and MicroProfile features
Use the Audit 2.0 feature to avoid generating unnecessary REST Handler records

Along with the new features and functions added to the runtime, we’ve also added a new guide to using MicroProfile Config.

View the list of fixed bugs in 24.0.0.8.

Check out previous Open Liberty GA release blog posts.

Develop and run your apps using 24.0.0.8

If you’re using Maven, include the following code in your pom.xml file:

<plugin>
    <groupId>io.openliberty.tools</groupId>
    <artifactId>liberty-maven-plugin</artifactId>
    <version>3.10.3</version>
</plugin>

Or for Gradle, include the following in your build.gradle file:

buildscript {
    repositories {
        mavenCentral()
    }
    dependencies {
        classpath 'io.openliberty.tools:liberty-gradle-plugin:3.8.3'
    }
}
apply plugin: 'liberty'

Or if you’re using container images:

FROM icr.io/appcafe/open-liberty

Or take a look at our Downloads page.

Streamline feature selection with versionless Jakarta EE, Java EE, and MicroProfile features

With Open Liberty, you configure only the features at the specific versions that your application needs. This composable design pattern minimizes runtime resource requirements and accelerates application startup times. However, you might not always know which version of a feature is compatible with the rest of your application configuration. In previous releases, determining the correct version typically required a mix of experimentation, guesswork, and digging deep into feature documentation. In 24.0.0.8 and later, versionless features automate version selection, enabling you to focus on application development without worrying about compatibility issues.

For example, instead of specifying servlet-6.0 in your server.xml file and having to figure out which other feature versions are compatible with Servlet 6.0, you can specify a platform version and servlet. The platform that you specify resolves all versionless features to a compatible version.

The following server.xml file configuration uses a Java EE platform of javaee-8.0 with associated versionless features that are defined for servlet, jpa, and jaxrs:

    <!-- Enable features -->
    <featureManager>
        <platform>javaee-8.0</platform>
        <feature>servlet</feature>
        <feature>jpa</feature>
        <feature>jaxrs</feature>
    </featureManager>

This example enables versionless MicroProfile features with microProfile-5.0 specified as the platform element:

    <!-- Enable features -->
    <featureManager>
        <platform>microProfile-5.0</platform>
        <feature>mpHealth</feature>
        <feature>mpMetrics</feature>
    </featureManager>

Note: The Liberty Maven and Gradle build plugins do not yet support versionless features or platform definitions.

Learn more and check out the full collection of available platforms and versionless features in the Open Liberty docs. Stay tuned for more versionless features and platforms in future releases.

Use the Audit 2.0 feature to avoid generating unnecessary REST Handler records

The 24.0.0.8 release introduces the Audit 2.0 feature (audit-2.0). The feature is designed for users who are not using REST Handler applications. It provides the same audit records as the Audit 1.0 feature (audit-1.0) but it does not generate records for REST Handler applications.

If you need to keep audit records for REST Handler applications, you can continue to use the Audit 1.0 feature.

To enable the Audit 2.0 feature in your application, add the following code to your server.xml file:

<featureManager>
    <feature>audit-2.0</feature>
</featureManager>

New guide: Externalizing environment-specific microservice configuration for CI/CD

A new guide is available under the Configuration category: Externalizing environment-specific microservice configuration for CI/CD. You’ll learn how to use MicroProfile Config’s configuration profiles to externalize configurations for different phases of the CI/CD lifecycle.

Get Open Liberty 24.0.0.8 now

Available through Maven, Gradle, Docker, and as a downloadable archive.

Recognize your cloud-native Java development skills with the Liberty Developer Essentials Badge

Tue, 06 Aug 2024 00:00:00 +0000

In a world where in-demand skills are critical for job success, security, and progression, it’s vital that we, as developers, ensure we are showcasing our skills to the wider world. This can include qualifications, courses, and badges, all of which help us to advertise our skills and highlight our professional experiences and expertise.

So, to help make this easier (and free!) for Java developers, the Open Liberty team created the first-ever Liberty badge: Liberty Developer Essentials!

This badge enables developers to showcase their ability to use open source technologies, such as Open Liberty, Jakarta EE, and MicroProfile, to effectively create a cloud-native Java application.

If you’re not familiar with Open Liberty, it is an open application framework that is designed for the cloud. It’s small, lightweight, and designed with modern cloud-native application development in mind. It supports the full MicroProfile and Jakarta EE APIs and is composable, meaning that you can use only the features that you need and keep everything lightweight, which is great for microservices. It also deploys to every major cloud platform, including Docker, Kubernetes, and Cloud Foundry. You can check out more about why developers love Liberty in this article on IBM Developer.

Who should apply for this badge?

New Java developers and experienced Java developers can both benefit from this badge!

New developers

If you’re new to the world of developing cloud-native Java applications and you’re looking for a good place to start, this badge and its corresponding course are a great starting point. By completing this course, you’ll learn practical, hands-on skills to effectively develop a basic Java application. You’ll then be able to apply these skills and be recognised for them through the associated badge that you can advertise on your CV, LinkedIn profile, and elsewhere.

Experienced developers:

Alternatively, if you already have experience developing cloud-native Java applications, you can benefit from this badge as a way to showcase and advertise your skills externally. If you’re a developer who is already using Liberty, this is a great way to easily show the experience you have and ability to use Liberty and other enterprise-level, open source technologies and standards to effectively create cloud-native Java applications.

On the other hand, if you’re experienced in developing cloud-native Java applications but have not used Liberty before, this course and badge offer you an opportunity to showcase your transferable skills, add Liberty to your tool belt, and widen the range of proven platforms that you can apply your development skills to.

How can I get this badge?

To earn the badge, there are two core components:

A hands-on course
An exam that tests the skills and knowledge learnt through the course

Hands-on Course

Developers who complete the Essentials for Cloud-Native Java Application Development beginner-level course on cognitiveclass.ai can earn this badge.

Note: If you’re already an experienced Liberty user, you’re also welcome to skip straight to the end exam.

This course teaches you the essential skills and technologies to create a basic cloud-native Java application with Open Liberty. It is composed of 5 modules that all involve hands-on coding experience using some of the Open Liberty interactive guides.

Course modules:

Getting started with Open Liberty
Creating a RESTful web service
Consuming a RESTful web service
Injecting dependencies into microservices
Configuring microservices

By completing these modules, you’ll learn about REST applications, contexts and dependency injection (CDI), externalizing application configuration, and more. All of these skills are essential for developing a basic cloud-native Java application. These modules utilise enterprise, open source, industry standards, including MicroProfile and Jakarta EE - skills that are especially important for developers working on enterprise applications.

There are no hard requirements to be able to take this course. However, a basic knowledge of Java, Maven, and microservices will be useful. It’s also worth noting that this is a self-paced course and can be taken at any time.

End Exam

At the end of the course, you’ll be presented with an exam to complete. To pass this end exam, you must score at least 80% on higher. The exam consists of 20 multiple-choice questions based on the skills and knowledge you gained by competing the the course.

Once you successfully pass this final exam, you’ll receive the Liberty Developer Essentials badge from Credly. You can then share this badge through social media sites like LinkedIn, or add it to things like your CV or email footer.

The first of many…

This badge is what we hope will be the first of many Liberty badges, enabling developers to learn and be recognised for various skills that are required for effective cloud-native Java app development. In the future, we aim to create badges that go beyond the beginner level into deeper, more challenging topics. Keep your eyes peeled for updates. If you have suggestions for badges you’d like to see, share them with us by creating an issue on the Open Liberty GitHub repository.

Get your Liberty Developer Essentials Badge today!

So, whether you’re new to Java development or a seasoned pro, get your Liberty Developer Essentials badge today and showcase your cloud-native Java application development skills! Once you’ve been awarded the badge, we’d love to see them on social media - please do tag us on X (@OpenLibertyIO) and LinkedIn (Open Liberty) so we can celebrate with you!

Simplify your runtime configuration with versionless features in 24.0.0.8-beta

Tue, 30 Jul 2024 00:00:00 +0000

This release simplifies choosing compatible features for the MicroProfile, Jakarta EE, and Java EE platforms by introducing versionless features. It also includes previews of Jakarta EE 11 and MicroProfile 7.0 beta features and a partitioned cookies function.

The Open Liberty 24.0.0.8-beta includes the following beta features (along with all GA features):

Streamline feature selection with versionless Jakarta EE and MicroProfile features
Keep using third party cookies with CHIPS

MicroProfile 7.0 beta features:

Enable the full set of MicroProfile 7.0 beta features with the MicroProfile 7.0 convenience feature
Integrate fault tolerance and OpenTelemetry with MicroProfile Fault Tolerance 4.1
Document APIs in OpenAPI 3.1 format with MicroProfile OpenAPI 4.0
Align your REST client with Jakarta RESTful Web Services with MicroProfile Rest Client 4.0
Collect and export HTTP metrics and logs with MicroProfile Telemetry 2.0

Jakarta EE 11 beta features:

Bring your own Jakarta Data provider with Jakarta Data API 1.0
Bring your own Jakarta Faces implementation with Jakarta Faces Container 4.1
Improve asynchronous handling with Jakarta WebSocket 2.2
Use Jakarta Persistence with improved type safety and other enhancements with Jakarta Persistence 3.2

Streamline feature selection with versionless Jakarta EE and MicroProfile features

With Open Liberty, you configure only the features at the specific versions that your application needs. This composable design pattern minimizes runtime resource requirements and accelerates application startup times. However, you might not always know which version of a feature is compatible with the rest of your application configuration. Determining the correct version typically requires a mix of experimentation, guesswork, and digging deep into feature documentation. Versionless features automate version selection, enabling you to focus on application development without worrying about compatibility issues.

Versionless features provide a generic way to specify Open Liberty features without having to specify a feature version. These new features are available for the MicroProfile, Jakarta EE, and Java EE platforms. When you use versionless features, you must specify a corresponding versioned platform element in your server.xml file.

The following server.xml file configuration uses a Java EE platform of javaee-8.0 with associated versionless features that are defined for servlet, jpa, and jaxrs:

Another example is specifying

    <!-- Enable features -->
    <featureManager>
        <platform>javaee-8.0</platform>
        <feature>servlet</feature>
        <feature>jpa</feature>
        <feature>jaxrs</feature>
    </featureManager>

This example enables versionless MicroProfile features with microProfile-5.0 specified as the platform element:

    <!-- Enable features -->
    <featureManager>
        <platform>microProfile-5.0</platform>
        <feature>mpHealth</feature>
        <feature>mpMetrics</feature>
    </featureManager>

Check out the full collection of available platforms and versionless features in the lists at the end of this post. Stay tuned for more information about versionless features in a forthcoming blog post and full documentation when versionless features are released for general availability (GA).

Known limitations

Error handling scenarios return generic messages.
Feature installation scenarios that use command-line tools, including Maven and Gradle plug-ins, are not supported.

To increase privacy and reduce tracking, Google Chrome announced it would phase out third-party cookies in 2025. Then, as of July 22, 2024, Chrome stated they might scrap the phase-out plan due to regulatory concerns. Users instead could opt to block third party cookies via their browser. Some sites that are designed with third-party cookies in mind are broken by browsers that opt-in to block third party cookies. Chrome provides documentation to help you test whether your sites are affected. If you are, one option to mitigate this change is called CHIPS: Cookies Having Independent Partitioned State.

First, some background information regarding third-party (cross-site) cookies.

If a top-level site X embeds another site Z, such as an iframe, then any cookies set by the embedded site Z might be shared with any other site that embeds site Z, such as top-level site Y. This vulnerability is due to cookies placed in a cookie jar under the Z site key. This scenario assumes that the cookie is labeled as SameSite=None, because it isn’t shared when set to Lax or Strict.

Chrome provides a Partitioned cookie attribute, which divides the cookie jar, as a workaround for third-party cookies with limitations. Instead of saving the cookies within the Z site key, they will also be keyed under the top-level site, such as X and Y. In this way, if X embeds Z and Y embeds Z, the Z’s cookies will not be shared between X and Y.

You can use the Partitioned attribute to specify whether a cookie is partitioned. If the SameSite=None attribute is missing from the cookie, it is blocked by Chrome and any Chromium-based browsers because it is treated as Lax.

The partitioned attribute configuration is opt-in and behaves much like the SameSite configuration. The samesite channel configuration applies to all cookies, while the httpSession and webAppSecurity configurations apply to their respective cookies. It’s important to note that the httpSession and webAppSecurity configurations take precedence over the channel configuration. The default value for these two attributes is defer, which means they defer to the channel configuration. As for channel configuration, its default value is false, which means the Partitioned attribute is not added.

Depending on which configuration you use to declare the Partitioned attribute, Liberty uses one of three attributes.

The following example shows how to set the cookiePartitioned attribute for the HTTP session cookie on the httpSession attribute in your server.xml file:

<httpSession cookieSameSite="None" cookiePartitioned="defer|true|false"/>`

The following example shows how to set the partitionedCookie attribute for LTPA and JWT security cookies on the webAppSecurity attribute in your server.xml file:

<webAppSecurity sameSiteCookie="None" partitionedCookie="defer|true|false"/>`

The following example shows how to set the partitioned attribute for other cookies on the httpEndpoint attribute in your server.xml file:

<httpEndpoint id="defaultHttpEndpoint"
              httpPort="9080"
              httpsPort="9443" >
   <samesite none="*" partitioned="true|false"/>
</httpEndpoint>

Alternatively, you can set Partitioned by using the Set-Cookie header with the following two HttpServletResponse APIs:

For more information, including a visual example, see CHIPS (Cookies Having Independent Partitioned State) on GitHub.

Enable the full set of MicroProfile 7.0 beta features with the MicroProfile 7.0 convenience feature

The 24.0.0.8-beta release includes the beta release of MicroProfile 7.0 and the microProfile-7.0 convenience feature.

MicroProfile 7.0 (MP 7.0) is a major release. It brings in Jakarta EE 10 and Jakarta 11 core profile APIs and the following MicroProfile component specifications:

The following 4 specifications have updates while the other 3 specifications remain unchanged.

MicroProfile Fault Tolerance 4.1
MicroProfile OpenAPI 4.0
MicroProfile Rest Client 4.0
MicroProfile Telemetry 2.0

MicroProfile Telemetry 2.0 now provides support for OpenTelemetry logs and metrics. Consequently, MicroProfile Metrics is not part of MicroProfile 7.0. However, the MicroProfile Metrics 5.1 feature is still compatible with MicroProfile 7.0 features.

To enable MicroProfile 7.0 and all its constituent features, add the microProfile-7.0 convenience feature to your server.xml file:

<featureManager>
    <feature>microProfile-7.0</feature>
</featureManager>

Integrate fault tolerance and OpenTelemetry with MicroProfile Fault Tolerance 4.1

MicroProfile Fault Tolerance helps you easily identify and mitigate failures in your code. It provides annotations that you can add to methods to use bulkhead, circuit breaker, retry, timeout, and fallback strategies.

The new mpFaultTolerance-4.1 feature integrates with the mpTelemetry-2.0 feature, so that Fault Tolerance can export metric data to OpenTelemetry. With this change, and other changes in mpTelemetry-2.0, you can simplify the configuration and management of your application observability by using OpenTelemetry as the single source for logging, metrics, and tracing.

To enable this functionality, enable mpFaultTolerance-4.1 and mpTelemetry-2.0 in your server.xml file and then configure mpTelemetry-2.0 to export metrics. The following examples show a minimal configuration for OpenTelemetry to export to your messages.log file and a class that generates Fault Tolerance metrics (it must be accessed as a CDI bean).

server.xml file configuration

<featureManager>
  <feature>mpFaultTolerance-4.1</feature>
  <feature>mpTelemetry-2.0</feature>
</featureManager>

bootstrap.properties file configuration

The following example configures OpenTelemetry to only output metrics to the messages.log file. It also sets a very low interval for exporting metrics so you can see the results quickly.

otel.sdk.disabled=false
otel.metrics.exporter=logging
otel.logs.exporter=none
otel.traces.exporter=none
otel.metric.export.interval=500

Example application class

Ensure that this class is injected as a CDI bean and invoked by the user in whatever way you prefer.

import org.eclipse.microprofile.faulttolerance.Retry;
import jakarta.enterprise.context.ApplicationScoped;

@ApplicationScoped
public class ExampleClass {

    @Retry
    public int exampleMethod(String name) {
        return 1;
    }
}

Learn more

You can read more details about the changes in the new version in the Microprofile Fault Tolerance 4.1 RC2 specification and API Javadoc.

You can learn more about how to use MicroProfile Fault Tolerance from our documentation and guides.

Document APIs in OpenAPI 3.1 format and more with MicroProfile OpenAPI 4.0

OpenAPI is a standardized way to document REST APIs in a JSON or YAML format. MicroProfile OpenAPI helps you generate and serve OpenAPI documentation for your REST applications that are built using JAX-RS or Jakarta RESTful Web Services. This documentation is useful for developers to test out the API during development, or for people using the API in production.

With the new MicroProfile OpenAPI 4.0 feature (mpOpenAPI-4.0), documentation is now produced in OpenAPI 3.1 format, updated from 3.0 in previous versions. Changes in OpenAPI 3.1 include:

Use of full JSON Schema 2020-12 draft for data object schemas (updated from a subset of an older JSON schema draft in 3.0)
Support for documenting webhooks
Reusable PathItems
Updates to the model API so that it directly reflects the OpenAPI 3.1 format
Additions to the annotations API to allow users to take advantage of the new features of OpenAPI 3.1

A detailed list of changes can be found in the release notes of the specification.

This is an early beta release to support the ratification of MicroProfile 7.0. As such, some function which was available in previous versions of the feature are not yet implemented:

Documenting more than one web module as can be configured in previous versions
Validation of the produced OpenAPI document

Learn more

For more information, see the following resources:

Align your REST client with Jakarta RESTful Web Services with MicroProfile Rest Client 4.0

MicroProfile Rest Client provides a type-safe approach to invoke RESTful services over HTTP. As much as possible, the MicroProfile Rest Client 4.0 release attempts to use Jakarta RESTful Web Services 3.1 APIs for consistency and easier re-use.

The MicroProfile Rest Client 4.0 feature (mpRestClient-4.0) aligns with Jakarta RESTful Web Services 3.1 as part of the greater effort to align MicroProfile 7.0 with Jakarta EE10. The beta release of this feature includes the following updates:

Added a new RestClientBuilder.header(String, Object) method to add dynamic headers to the request.
Added a new RestClientBuilder.baseUri(String) overload method so users don’t have to call URI.create(String).
Added clarification in the spec on how to use Jakarta RESTful Web Services EntityPart API for multipart requests.

Learn more

For more information, see the following resources:

Collect and export HTTP metrics and logs with MicroProfile Telemetry 2.0

MicroProfile Telemetry 2.0 (mpTelemetry-2.0) provides developers with the latest OpenTelemetry technology. The feature now consumes OpenTelemetry-1.34.0. In addition to distributed tracing, the feature now allows OpenTelemetry to collect and export HTTP metrics and logs.

To enable the mpTelemetry-2.0 feature to collect metrics, logs, and traces, add the following configuration to your server.xml file:

<featureManager>
   <feature>mpTelemetry-2.0</feature>
</featureManager>

Additionally, you must add the following configuration to your server.xml file to make third-party APIs visible for your application:

<webApplication location="application-name.war" contextRoot="/">
    <!-- enable visibility to third party apis -->
    <classloader apiTypeVisibility="+third-party"/>
</webApplication>

HTTP Metrics

In the 24.0.0.7-beta release, we introduced Enhanced HTTP Request Monitoring with Monitor 1.0. This update enables you to track HTTP requests made to the server and record the following data:

Request method
Response status
Duration
HTTP route
Other attributes that align with the OpenTelemetry HTTP metric semantic conventions.

This information is recorded into an HttpStatsMXBean. If the MicroProfile Metrics 5.0 or later feature (mpMetrics-5.x) is enabled, then the HTTP metrics are reported on the /metrics REST endpoint.

In this beta release, we can now register HTTP Metrics with the mpTelemetry-2.0 feature. This metric data can then be exported to a compatible OpenTelemetry metrics consumer. This enhancement is an auto-feature that activates with mpTelemetry-2.0, monitor-1.0, and any feature that uses the servlet engine that currently supports Jakarta EE 10 features, such as servlet-6.0, pages-3.1, and restfulWS-3.1.

Logs

Logs generated by the java.util.logging (JUL) package and message logs can now be collected by OpenTelemetry with the mpTelemetry-2.0 feature.

To collect and export runtime-level logs and metrics, enable OpenTelemetry by using the following system property or environment variable:

System property: otel.sdk.disabled=false
Environment variable: OTEL_SDK_DISABLED=false

To separately configure for multiple applications on a server, you can configure OpenTelemetry at the application level. However, you cannot collect runtime-level logs and metrics with this configuration.

By default, all OpenTelemetry data is exported to the OTLP. You can change each exporter with the following system properties and variables.

System properties:

otel.metrics.exporter
otel.logs.exporter
otel.traces.exporter

Environment variables:

OTEL_METRICS_EXPORTER
OTEL_LOGS_EXPORTER
OTEL_TRACES_EXPORTER

MicroProfile Telemetry 2.0 beta known issues

Tracing context is not transferred through threads in REST Client async requests. Therefore, context values are inconsistent with parent and child spans.

Bring your own Jakarta Data provider with Jakarta Data API 1.0

Jakarta Data 1.0 is a new Jakarta EE specification that standardizes a repository-based programming model for data access across relational and non-relational databases.

The Jakarta Data API feature (dataContainer-1.0) enables you to use third-party Jakarta Data providers in Open Liberty without including the built-in provider for EclipseLink. This configuration is useful if you want to use a different Jakarta Persistence-based Jakarta Data provider, such as Hibernate, without colliding on the Jakarta Persistence Entity annotation. It’s also useful if you want to use Jakarta NoSQL exclusively and do not want the overhead of the built-in provider for relational databases.

To use a third-party Jakarta Data provider, enable the dataContainer-1.0 feature in your server.xml file. You can then include a third-party Jakarta Data provider in your server configuration by using the library element.

The following server.xml file example shows the configuration to use the Eclipse jNoSQL Jakarta Data provider and a MongoDB database:

  <featureManager>
    <feature>dataContainer-1.0</feature>

    <!-- Features needed for jNoSQL config / processing -->
    <feature>mpConfig-3.1</feature>
    <feature>jsonb-3.0</feature>
  </featureManager>

  <library id="jnosql">
          <!-- Jakarta NoSQL API -->
          <fileset dir="${shared.resource.dir}/nosql" includes="jakarta.nosql-api.jar" />
          <!-- Eclipse jNoSQL Implementation of Jakarta NoSQL and Jakarta Data -->
    <fileset dir="${shared.resource.dir}/jnosql"
            includes="jnosql-communication-core.jar jnosql-mapping-core.jar jnosql-mongodb.jar *.jar" />
    <!-- Mongo java driver -->
    <fileset dir="${shared.resource.dir}/mongodb"
            includes="mongodb-driver-core.jar mongodb-driver-sync.jar" />
  </library>

  <!-- MongoDB connection configuration -->
  <variable name="jnosql.mongodb.host" value="${MONGO_HOST}"/>
  <variable name="jnosql.document.database" value="${MONGO_DBNAME}"/>

  <application location="MyApplication.war">
    <classloader commonLibraryRef="jnosql" />
  </application>

To use a third-party Jakarta Persistence-based Jakarta Data provider, include the dataContainer-1.0 and persistenceContainer-3.2 features. You can then include the third-party Jakarta Data provider in your server configuration by using a library element.

The following server.xml file example shows the configuration to use the Hibernate ORM Jakarta Data provider and a PostgreSQL database:

  <featureManager>
    <feature>dataContainer-1.0</feature>
    <feature>persistenceContainer-3.2</feature>

    <!-- Features needed for Hibernate config / processing -->
    <feature>xmlBinding-4.0</feature>
  </featureManager>

  <!-- Hibernate Implementation of Jakarta Persistence and Jakarta Data -->
  <library id="hibernate">
      <fileset dir="${shared.resource.dir}/hibernate"
        includes="hibernate-core.jar hibernate-models.jar *.jar"/>
  </library>

  <!-- PostgreSQL JDBC driver -->
  <library id="postgresql">
      <fileset dir="${shared.resource.dir}/postgresql" includes="*.jar"/>
  </library>

  <!-- Datasource used to create a Persistence Unit -->
  <dataSource jndiName="jdbc/postgresql" >
    <jdbcDriver libraryRef="postgresql"/>
    <properties.postgresql URL="${POSTGRESQL_URL}"/>
  </dataSource>

  <application location="MyApplication.war">
    <classloader commonLibraryRef="hibernate, postgresql" />
  </application>

Hibernate ORM uses a persistence unit to persist entities that are defined on a Jakarta Data repository interface. To create a persistence unit, add a META-INF/persistence.xml deployment descriptor file to your application, similar to the following example.

  <persistence xmlns="https://jakarta.ee/xml/ns/persistence"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="https://jakarta.ee/xml/ns/persistence https://jakarta.ee/xml/ns/persistence/persistence_3_2.xsd"
         version="3.2">

  <persistence-unit name="postgresql-pu">
        <provider>org.hibernate.jpa.HibernatePersistenceProvider</provider>
    <jta-data-source>jdbc/postgresql</jta-data-source>
    <properties>
      <property name="jakarta.persistence.schema-generation.database.action" value="create"/>
    </properties>
  </persistence-unit>

  </persistence>

Learn more

For more information, see the following resources:

Bring your own Jakarta Faces implementation with Jakarta Faces Container 4.1

Jakarta Faces is a Model-View-Controller (MVC) framework for building web applications. It offers many convenient features, such as state management and input validation.

The Jakarta Faces Container 4.1 feature (facesContainer-4.1) enables you to bring your own Jakarta Faces API and implementation to Liberty. The alternative is to use the Liberty-provided faces-4.1 feature, which provides the MyFaces 4.1 API and implementation.

The Faces Container feature is updated in this beta release to support the 4.1 API and implementation JARs. If the 4.1 JARs were used with earlier features, errors occurred because the feature checks against the specification version listed within the jars.

To use the facesContainer-4.1 feature, add the following configuration to your server.xml file:

<featureManager>
   <feature>facesContainer-4.1</feature>
</featureManager>

Learn more

For more information, see the following resources:

Improve asynchronous handling with Jakarta WebSocket 2.2

The Jakarta WebSocket 2.2 (websocket-2.2) feature enables communication for endpoints by using the WebSocket protocol. It is an implementation of the Jakarta EE 11 WebSocket 2.2 Specification.

Although very few specification changes were listed for the 2.2 release, the main change from 2.1 is the introduction of the getSession() method on the SendResult class. This method enables you to retrieve the original session that was used in the asynchronous remote call. This capability is useful for broadcasting messages to numerous listening clients.

To enable this feature, add the following configuration to your server.xml file.

 <featureManager>
    <feature>websocket-2.2</feature>
</featureManager>

Learn more

For more information, such as the Javadocs, specification documents, and other details, see the Jakarta WebSocket 2.2 specification document and Send bidirectional messages between services with WebSocket in the Open Liberty docs.

Use Jakarta Persistence with improved type safety and other enhancements with Jakarta Persistence 3.2

The Jakarta Persistence feature (persistence-3.2) provides an object-model approach to persist, fetch, and modify data that is stored on a relational database system.

Jakarta Persistence 3.2 includes the following updates:

Improve type safety of the find() and refresh() methods
Provide schema management programmatically
Allow Java records as embeddable types
Add functions and operators to the JPQL/Criteria API, such as left, right, replace, || operator, cast, union, union all, intersect, intersect all, except, and except all
Support for subqueries in the select, from, and join clauses.

To use the persistence-3.2 feature, add the following configuration to your server.xml file:

<featureManager>
   <feature>persistence-3.2</feature>
</featureManager>

This feature uses Eclipselink 5.0 beta release as the Jakarta Persistence provider. To bring your own 3rd party persistence provider, enable the persistenceContainer-3.2 feature instead:

<featureManager>
   <feature>persistenceContainer-3.2</feature>
</featureManager>

Learn more

For more information, see the Data persistence with the Jakarta Persistence API in the Open Liberty docs and the Jakarta Persistence 3.2 specification document.

Try it now

To try out these features, update your build tools to pull the Open Liberty All Beta Features package instead of the main release. The beta works with Java SE 22, Java SE 21, Java SE 17, Java SE 11, and Java SE 8. However, Java SE 17 or later is required for the Jakarta EE 11 features that are in the beta.

If you’re using Maven, you can install the All Beta Features package using:

<plugin>
    <groupId>io.openliberty.tools</groupId>
    <artifactId>liberty-maven-plugin</artifactId>
    <version>3.10.3</version>
    <configuration>
        <runtimeArtifact>
          <groupId>io.openliberty.beta</groupId>
          <artifactId>openliberty-runtime</artifactId>
          <version>24.0.0.8-beta</version>
          <type>zip</type>
        </runtimeArtifact>
    </configuration>
</plugin>

<dependency>
    <groupId>org.example.spec</groupId>
    <artifactId>exampleApi</artifactId>
    <version>7.0</version>
    <type>pom</type>
    <scope>provided</scope>
</dependency>
<dependency>
    <groupId>example.platform</groupId>
    <artifactId>example.example-api</artifactId>
    <version>11.0.0</version>
    <scope>provided</scope>
</dependency>

Or for Gradle:

buildscript {
    repositories {
        mavenCentral()
    }
    dependencies {
        classpath 'io.openliberty.tools:liberty-gradle-plugin:3.8.3'
    }
}
apply plugin: 'liberty'
dependencies {
    libertyRuntime group: 'io.openliberty.beta', name: 'openliberty-runtime', version: '[24.0.0.8-beta,)'
}

Or if you’re using container images:

FROM icr.io/appcafe/open-liberty:beta

Or take a look at our Downloads page.

For more information on using a beta release, refer to the Installing Open Liberty beta releases documentation.

We welcome your feedback

Let us know what you think on our mailing list. If you hit a problem, post a question on StackOverflow. If you hit a bug, please raise an issue.

Platforms and related versionless features reference list

The following platform features are available in this beta release. You can specify up to 2 platform elements, one for MicroProfile, another for either Jakarta EE or Java EE.

MicroProfile

Platforms

microProfile-1.2
microProfile-1.3
microProfile-1.4
microProfile-2.0
microProfile-2.1
microProfile-2.2
microProfile-3.0
microProfile-3.2
microProfile-3.3
microProfile-4.0
microProfile-4.1
microProfile-5.0
microProfile-6.0
microProfile-6.1
microProfile-7.0

Versionless features

mpConfig
mpFaultTolerance
mpHealth
mpJwt
mpMetrics
mpOpenAPI
mpOpenTracing
mpRestClient
mpTelemetry

Jakarta EE and Java EE

Platforms

javaee-7.0
javaee-8.0
jakartaee-9.1
jakartaee-10.0
jakartaee-11.0

Versionless features

Although Liberty uses different feature names and short names for some Java EE and Jakarta EE versions of the same feature, you can use either short name and the platform you specify pulls in the correct compatible feature.

appAuthentication or jaspic
appAuthorization or jacc
appClientSupport
appSecurity
batch
beanValidation
cdi
concurrent
connectors or jca
connectorsInboundSecurity or jcaInboundSecurity
data
enterpriseBeans or ejb
enterpriseBeansHome or ejbHome
enterpriseBeansLite or ejbLite
enterpriseBeansPersistentTimer or ejbPersistentTimer
enterpriseBeansRemote or ejbRemote
expressionLanguage or el
faces or jsf
j2eeManagement
jdbc
jsonb
jsonp
mail or javaMail
managedBeans
mdb
messaging or jms
messagingClient or wasJmsClient
messagingSecurity or wasJmsSecurity
messagingServer or wasJmsServer
pages or jsp
persistence or jpa
restfulWS or jaxrs
restfulWSClient or jaxrsClient
servlet
websocket
xmlBinding or jaxb
xmlWS or jaxws

Enhancements in Jakarta RESTful Web Services 4.0 and more in 24.0.0.7-beta

Tue, 02 Jul 2024 00:00:00 +0000

The 24.0.0.7-beta release introduces enhancements to Jakarta RESTful Web Services 4.0, including new API methods and media type values. It also includes enhanced HTTP request tracking and the beta release of the Audit 2.0 feature, which creates REST Handler records only when a REST Handler application is configured.

The Open Liberty 24.0.0.7-beta includes the following beta features (along with all GA features):

Jakarta Restful Web Services 4.0 (EE11)
Enhanced HTTP Request Monitoring with Monitor 1.0
Jakarta EE11 Faces 4.1
Use the Audit 2.0 feature to avoid generating unnecessary REST Handler records

Jakarta Restful Web Services 4.0 (EE11)

Jakarta RESTful Web Services provides a foundational API to develop web services based on the REST architectural pattern. The Jakarta Restful Web Services 4.0 update introduces several enhancements to make web service development more efficient and effective.

The new features, restfulWS-4.0 and restfulWSClient-4.0, are primarily aimed at application developers. This release brings incremental improvements to Jakarta RESTful Web Services. It provides the following new convenience API methods:

The containsHeaderString() method is added to ContainerRequestContext, ContainerResponseContext, and HttpHeaders to help determine whether a header contains a specified value.
The UriInfo.getMatchedResourceTemplate() method is a new addition that returns a full template for a request.
New MediaType values to handle specific media types are introduced, including APPLICATION_JSON_PATCH_JSON and APPLICATION_MERGE_PATCH_JSON.

These updates streamline the process of developing RESTful services. To implement these new features, add the following code to your server.xml file.

For the RESTful web services feature:

<featureManager>
    <feature>restfulWS-4.0</feature>
</featureManager>

For the RESTful web services client feature:

<featureManager>
    <feature>restfulWSClient-4.0</feature>
</featureManager>

For more information, see the Jakarta RESTful Web Services 4.0 specification and the Javadoc.

Enhanced HTTP Request Monitoring with Monitor 1.0

Open Liberty introduces a significant update that enhances the tracking of HTTP connections that are made to the server. With the Monitor-1.0 feature (monitor-1.0) and any Jakarta EE 10 feature that uses the servlet engine, Open Liberty can now record detailed information about HTTP requests into an HttpStatsMXBean. This includes the request method, response status, duration, HTTP route, and other attributes that align with the Open Telemetry HTTP metric semantic convention.

If the mpMetrics-5.0 or mpMetrics-5.1 feature is also active, Open Liberty creates corresponding HTTP metrics, such as http.server.request.duration, using a Timer type metric. To use these metrics effectively, configure histogram buckets explicitly for Timer and Histogram type metrics by using the MicroProfile Metrics feature. For more details, see the mp.metrics.distribution.timer.buckets property on the MicroProfile Config Properties page.

This update ensures that operations teams responsible for monitoring can now have a detailed and comprehensive view of HTTP requests, enhancing the monitoring and management capabilities within Open Liberty environments.

Previously, Open Liberty tracked servlet and JAX-RS/RESTful resource requests to the server as separate MBeans (servlet MBeans and REST MBeans). This data might then be forwarded to the mpMetrics feature to create corresponding metrics. Monitoring tools like Prometheus and Grafana could visualize this metric data to showcase server performance and responsiveness.

With the new update, HTTP connections are now tracked more comprehensively, combining request details into a unified HttpStatsMXBean. This approach simplifies monitoring and provides a more cohesive view of server performance, making it easier for operations teams to ensure optimal server responsiveness.

This enhancement is an auto-feature that activates with monitor-1.0 and any feature that uses the servlet engine currently supporting Jakarta EE 10 features like servlet-6.0, pages-3.1, and restfulWS-3.1. It also supports registering HTTP metrics with mpMetrics-5.x features. To enable this function, add the following to your server.xml file:

<featureManager>
    <feature>monitor-1.0</feature>
    <feature>servlet-6.0</feature>
    <feature>mpMetrics-5.0</feature>
</featureManager>

For detailed configuration, see the MicroProfile Config Properties page.

For more information about the HTTP semantic convention used, see the Open Telemetry HTTP semantic convention page.

Jakarta EE11 Faces 4.1

Jakarta Faces is a Model-View-Controller (MVC) framework for building web applications, offering many convenient features, such as state management and input validation. The Jakarta Faces 4.1 (faces-4.1) update introduces a range of incremental improvements to enhance the developer experience. These enhancements include increased use of generics in FacesMessages and other locations, as well as improved CDI integration by requiring events for @Initialized, @BeforeDestroyed, and @Destroyed for built-in scopes like FlowScoped and ViewScoped. The current Flow can also now be injected into a backing bean. Finally, a new UUIDConverter is added to the API, which simplifies the handling of UUIDs.

This update also includes some deprecations and removals. The composite:extension tag and references to the Security Manager are removed, and the full state saving mechanism is deprecated. To enable the Jakarta Faces 4.1 feature in your application, add the following to your server.xml file:

<featureManager>
    <feature>faces-4.1</feature>
</featureManager>

For more information, see the Jakarta Faces 4.1 specification and the Javadoc.

Use the Audit 2.0 feature to avoid generating unnecessary REST Handler records

The Audit 2.0 feature (audit-2.0) is now in beta release. The feature is designed for users that are not using REST Handler applications. It provides the same audit records as the Audit 1.0 feature (audit-1.0) but it does not generate records for REST Handler applications.

Customers that need to keep audit records for REST Handler applications must continue to use the Audit 1.0 feature.

To enable the Audit 2.0 feature in your application, add the following to your server.xml file:

<featureManager>
    <feature>audit-2.0</feature>
</featureManager>

Try it now

To try out these features, update your build tools to pull the Open Liberty All Beta Features package instead of the main release. The beta works with Java SE 21, Java SE 17, Java SE 11, and Java SE 8.

If you’re using Maven, you can install the All Beta Features package using:

<plugin>
    <groupId>io.openliberty.tools</groupId>
    <artifactId>liberty-maven-plugin</artifactId>
    <version>3.10.3</version>
    <configuration>
        <runtimeArtifact>
          <groupId>io.openliberty.beta</groupId>
          <artifactId>openliberty-runtime</artifactId>
          <version>24.0.0.7-beta</version>
          <type>zip</type>
        </runtimeArtifact>
    </configuration>
</plugin>

<dependency>
    <groupId>org.example.spec</groupId>
    <artifactId>exampleApi</artifactId>
    <version>7.0</version>
    <type>pom</type>
    <scope>provided</scope>
</dependency>
<dependency>
    <groupId>example.platform</groupId>
    <artifactId>example.example-api</artifactId>
    <version>11.0.0</version>
    <scope>provided</scope>
</dependency>

Or for Gradle:

buildscript {
    repositories {
        mavenCentral()
    }
    dependencies {
        classpath 'io.openliberty.tools:liberty-gradle-plugin:3.8.3'
    }
}
apply plugin: 'liberty'
dependencies {
    libertyRuntime group: 'io.openliberty.beta', name: 'openliberty-runtime', version: '[24.0.0.7-beta,)'
}

Or if you’re using container images:

FROM icr.io/appcafe/open-liberty:beta

Or take a look at our Downloads page.

For more information on using a beta release, refer to the Installing Open Liberty beta releases documentation.

We welcome your feedback

Let us know what you think on our mailing list. If you hit a problem, post a question on StackOverflow. If you hit a bug, please raise an issue.

Jakarta EE11 previews and more in 24.0.0.6-beta

Tue, 04 Jun 2024 00:00:00 +0000

The 24.0.0.6-beta release includes previews of the Jakarta Validation and Jakarta Data implementations, both of which are part of Jakarta EE 11. The release also includes enhancements for histogram and timer metrics in MicroProfile 3.0 and 4.0 and InstantOn support for distributed HTTP session caching.

The Open Liberty 24.0.0.6-beta includes the following beta features (along with all GA features):

Validate Java constraints and records with Jakarta Validation 3.1
Preview of Jakarta Data (Release Candidate 1)
Enhanced histogram and timer metrics in MicroProfile 3.0 and 4.0
InstantOn support for distributed HTTP session caching

Validate Java constraints and records with Jakarta Validation 3.1

Jakarta Validation provides a mechanism to validate constraints that are imposed on Java objects by using annotations. The most noticeable change in version 3.1 is the name change, from Jakarta Bean Validation to Jakarta Validation. This version also includes explicit support for validating Java record classes, which were added in Java 16. Records reduce much of the boilerplate code in simple data classes, and pair nicely with Jakarta Validation.

The following examples demonstrate the simplicity of defining a Java record with Jakarta Validation annotations, as well as performing validation.

In this example, an Employee record is defined with two fields, empid and email.

public record Employee(@NotEmpty String empid, @Email String email) {}

The @NotEmpty annotation specifies that empid cannot be an empty string, while the @Email annotation specifies that the value for email must be a properly formatted email address.

In this example, a validator is created to check the specified Employee values against the constraints that were set in the previous example.

Employee employee = new Employee("12432", "mark@example.com");
Set<ConstraintViolation<Employee>> violations = validator.validate(employee);

Preview of Jakarta Data (Release Candidate 1)

Jakarta Data is a new Jakarta EE specification being developed in the open that aims to standardize the popular Data Repository pattern across various providers. Open Liberty 24.0.0.6-beta includes the Jakarta Data 1.0 release candidate 1, which decouples sorting from pagination, improves the static metamodel, and completes the initial definition of Jakarta Data Query Language (JDQL).

The Open Liberty beta includes a test implementation of Jakarta Data that we are using to experiment with proposed specification features. You can try out these features and provide feedback to influence the Jakarta Data 1.0 specification as it continues to be developed. The test implementation currently works with relational databases and operates by redirecting repository operations to the built-in Jakarta Persistence provider.

Jakarta Data 1.0 Release Candidate 1 completes the definition of Jakarta Data Query Language (JDQL) as a subset of Jakarta Persistence Query Language (JPQL). JDQL allows basic comparison and update operations on a single type of entity (an entity identifier variable is not used), as well as the ability to perform deletion and count operations. Find operations in JDQL consist of SELECT, FROM, WHERE, and ORDER BY clauses, all of which are optional.

Jakarta Data 1.0 Release Candidate 1 decouples sorting from pagination, allowing you to request pages of results without needing to duplicate the specification of the entity type that is queried.

The static metamodel, which allows for more type-safe usage, is streamlined in Release Candidate 1 to allow the use of interface classes with constant fields to define the metamodel.

To use these capabilities, you need an Entity and a Repository.

Annotated with jakarta.persistence.Entity and related annotations from Jakarta Persistence
A Java class without entity annotations, in which case the primary key is inferred from an entity property that is named id or ends with Id and an entity property that is named version designates an automatically incremented version column.

You define one or more repository interfaces for an entity, annotate those interfaces as @Repository, and inject them into components by using @Inject. The Jakarta Data provider supplies the implementation of the repository interface for you.

The following example shows a simple entity:

@Entity
public class Product {
    @Id
    public long id;

    public boolean isDiscounted;

    public String name;

    public float price;

    @Version
    public long version;
}

Here is a repository that defines operations relating to the entity. Your repository interface can inherit from built-in interfaces, such as BasicRepository and CrudRepository, to gain various general-purpose repository methods for inserting, updating, deleting, and querying for entities. You can add methods to further customize it.

@Repository(dataStore = "java:app/jdbc/my-example-data")
public interface Products extends BasicRepository<Product, Long> {
    @Insert
    Product add(Product newProduct);

    // query-by-method name pattern:
    List<Product> findByNameIgnoreCaseContains(String searchFor, Order<Product> orderBy);

    // parameter based query that does not require -parameters because it explicitly specifies the name
    @Find
    Page<Product> find(@By("isDiscounted") boolean onSale,
                       PageRequest pageRequest,
                       Order <Product> orderBy);

    // find query in JDQL that requires compilation with -parameters to preserve parameter names
    @Query("SELECT price FROM Product WHERE id=:productId")
    Optional<Float> getPrice(long productId);

    // update query in JDQL:
    @Query("UPDATE Product SET price = price - (?2 * price), isDiscounted = true WHERE id = ?1")
    boolean discount(long productId, float discountRate);

    // delete query in JDQL:
    @Query("DELETE FROM Product WHERE name = ?1")
    int discontinue(String name);
}

Observe that the repository interface includes type parameters in PageRequest<Product> and Order<Product>. These parameters help ensure that the page request and sort criteria are for a Product entity rather than some other entity. To accomplish this, you can optionally define a static metamodel class for the entity (or various IDEs might generate one for you after the 1.0 specification is released). Here is one that can be used with the Product entity:

@StaticMetamodel(Product.class)
public interface _Product {
    String ID = "id";
    String IS_DISCOUNTED = "isDiscounted";
    String NAME = "name";
    String PRICE = "price";
    String VERSION = "version";

    SortableAttribute<Product> id = new SortableAttributeRecord(ID);
    SortableAttribute<Product> isDiscounted = new SortableAttributeRecord(IS_DISCOUNTED);
    TextAttribute<Product> name = new TextAttributeRecord(NAME);
    SortableAttribute<Product> price = new SortableAttributeRecord(PRICE);
    SortableAttribute<Product> version = new SortableAttributeRecord(VERSION);
}

The following example shows the repository and static metamodel being used:

@DataSourceDefinition(name = "java:app/jdbc/my-example-data",
                      className = "org.postgresql.xa.PGXADataSource",
                      databaseName = "ExampleDB",
                      serverName = "localhost",
                      portNumber = 5432,
                      user = "${example.database.user}",
                      password = "${example.database.password}")
public class MyServlet extends HttpServlet {
    @Inject
    Products products;

    protected void doGet(HttpServletRequest req, HttpServletResponse resp)
            throws ServletException, IOException {
        // Insert:
        Product prod = ...
        prod = products.add(prod);

        // Find the price of one product:
        price = products.getPrice(productId).orElseThrow();

        // Find all, sorted:
        List<Product> all = products.findByNameIgnoreCaseContains(searchFor, Order.by(
                                     _Product.price.desc(),
                                     _Product.name.asc(),
                                     _Product.id.asc()));

        // Find the first 20 most expensive products on sale:
        Page<Product> page1 = products.find(onSale, PageRequest.ofSize(20), Order.by(
                                       _Product.price.desc(),
                                       _Product.name.asc(),
                                       _Product.id.asc()));
        ...
    }
}

Enhanced histogram and timer metrics in MicroProfile 3.0 and 4.0

This release introduces MicroProfile Config properties for MicroProfile 3.0 and 4.0 that are used for configuring the statistics that are tracked and outputted by the histogram and timer metrics. These changes are already available in MicroProfile Metrics 5.1.

In previous MicroProfile Metrics 3.0 and 4.0 releases, histogram and timer metrics tracked only the following values:

Min/max recorded values
The sum of all values
The count of the recorded values
A static set of percentiles for the 50th, 75th, 95th, 98th, 99th and 99.9th percentile.

These values are output to the /metrics endpoint in Prometheus format.

The new properties can define a custom set of percentiles as well as custom set of histogram buckets for the histogram and timer metrics. Other new configuration properties can enable a default set of histogram buckets, including properties that define an upper and lower bound for the bucket set.

With these properties, you can define a semicolon-separated list of value definitions that use the following syntax:

<metric name>=<value-1>[,<value-2>…<value-n>]

Some properties can accept multiple values for a given metric name, while others can accept only a single value.

You can use an asterisk ( *) as a wildcard at the end of the metric name.

Property

Description

mp.metrics.distribution.percentiles

Defines a custom set of percentiles for matching Histogram and Timer metrics to track and output. Accepts a set of integer and decimal values for a metric name pairing. Can be used to disable percentile output if no value is provided with a metric name pairing.

mp.metrics.distribution.histogram.buckets

Defines a custom set of (cumulative) histogram buckets for matching Histogram metrics to track and output. Accepts a set of integer and decimal values for a metric name pairing.

mp.metrics.distribution.timer.buckets

Defines a custom set of (cumulative) histogram buckets for matching Timer metrics to track and output. Accepts a set of decimal values with a time unit appended (that is, ms, s, m, h) for a metric name pairing.

mp.metrics.distribution.percentiles-histogram.enabled

Configures any matching Histogram or Timer metric to provide a large set of default histogram buckets to allow for percentile configuration with a monitoring tool. Accepts a true/false value for a metric name pairing.

mp.metrics.distribution.histogram.max-value

When percentile-histogram is enabled for a Timer, this property defines an upper bound for the buckets reported. Accepts a single integer or decimal value for a metric name pairing.

mp.metrics.distribution.histogram.min-value

When percentile-histogram is enabled for a Timer, this property defines a lower bound for the buckets reported. Accepts a single integer or decimal value for a metric name pairing.

mp.metrics.distribution.timer.max-value

When percentile-histogram is enabled for a Histogram, this property defines an upper bound for the buckets reported. Accepts a single decimal value with a time unit appended (that is, ms, s, m, h) for a metric name pairing. Accepts a single decimal value with a time unit appended (that is, ms, s, m, h) for a metric name pairing.

mp.metrics.distribution.timer.min-value

When percentile-histogram is enabled for a Histogram, this property defines a lower bound for the buckets reported. Accepts a single decimal value with a time unit appended (that is, ms, s, m, h) for a metric name pairing.

You can define the mp.metrics.distribution.percentiles property similar to the following example.

mp.metrics.distribution.percentiles=alpha.timer=0.5,0.7,0.75,0.8;alpha.histogram=0.8,0.85,0.9,0.99;delta.*=

This property creates the alpha.timer timer metric to track and output the 50th, 70th, 75th, and 80th percentile values. The alpha.histogram histogram metric outputs the 80th, 85th, 90th, and 99th percentile values. Percentiles for any histogram or timer metric that matches with delta.* are disabled.

We’ll expand on this example and define histogram buckets for the alpha.timer timer metric by using the mp.metrics.distribution.timer.buckets property.

mp.metrics.distribution.timer.buckets=alpha.timer=100ms,200ms,1s

This configuration tells the metrics runtime to track and output the count of durations that fall within 0-100ms, 0-200ms and 0-1 seconds. This output is due to the histogram buckets working in a cumulative fashion.

The corresponding prometheus output for the alpha.timer metric at the /metrics REST endpoint is similar to the following example:

# TYPE application_alpha_timer_mean_seconds gauge
application_alpha_timer_mean_seconds 2.9700022497975187
# TYPE application_alpha_timer_max_seconds gauge
application_alpha_timer_max_seconds 5.0
# TYPE application_alpha_timer_min_seconds gauge
application_alpha_timer_min_seconds 1.0
# TYPE application_alpha_timer_stddev_seconds gauge
application_alpha_timer_stddev_seconds 1.9997750210918204
# TYPE alpha_timer_seconds histogram (1)
application_alpha_timer_seconds_bucket{le="0.1"} 0.0 (2)
application_alpha_timer_seconds_bucket{le="0.2"} 0.0 (2)
application_alpha_timer_seconds_bucket{le="1.0"} 1.0 (2)
application_alpha_timer_seconds_bucket{le="+Inf"} 2.0 (2) (3)
application_alpha_timer_seconds_count 2
application_alpha_timer_seconds_sum 6.0
application_alpha_timer_seconds{quantile="0.5"} 1.0
application_alpha_timer_seconds{quantile="0.7"} 5.0
application_alpha_timer_seconds{quantile="0.75"} 5.0
application_alpha_timer_seconds{quantile="0.8"} 5.0

1	The Prometheus metric type is `histogram`. Both the quantiles/percentile and buckets are represented under this type.
2	The `le` tag represents less than and is for the defined buckets, which are converted to seconds.
3	Prometheus requires that a `+Inf` bucket counts all hits.

InstantOn support for distributed HTTP session caching

Open Liberty InstantOn provides fast startup times for MicroProfile and Jakarta EE applications. With InstantOn, your applications can start in milliseconds, without compromising on throughput, memory, development-production parity, or Java language features. InstantOn uses the Checkpoint/Restore In Userspace (CRIU) feature of the Linux kernel to take a checkpoint of the JVM that can be restored later.

The 24.0.0.6-beta release provides InstantOn support for the JCache Session Persistence feature. This feature uses a JCache provider to create a distributed in-memory cache. Distributed session caching is achieved when the server is connected to at least one other server to form a cluster. Open Liberty servers can behave in the following ways in a cluster.

Client-server model: An Open Liberty server can act as the JCache client and connect to a dedicated JCache server.
Peer-to-Peer model: An Open Liberty server can connect with other Open Liberty servers that are also running with the JCache Session Persistence feature and configured to be part of the same cluster.

To enable JCache Session Persistence, the sessionCache-1.0 feature must be enabled in your server.xml file:

<feature>sessionCache-1.0</feature>

You can configure the client/server model in the server.xml file, similar to the following example.

<library id="InfinispanLib">
    <fileset dir="${shared.resource.dir}/infinispan" includes="*.jar"/>
</library>
<httpSessionCache cacheManagerRef="CacheManager"/>
<cacheManager id="CacheManager">
    <properties
        infinispan.client.hotrod.server_list="infinispan-server:11222"
        infinispan.client.hotrod.auth_username="sampleUser"
        infinispan.client.hotrod.auth_password="samplePassword"
        infinispan.client.hotrod.auth_realm="default"
        infinispan.client.hotrod.sasl_mechanism="PLAIN"
        infinispan.client.hotrod.java_serial_whitelist=".*"
        infinispan.client.hotrod.marshaller=
            "org.infinispan.commons.marshall.JavaSerializationMarshaller"/>
    <cachingProvider jCacheLibraryRef="InfinispanLib" />
</cacheManager>

You can configure the peer-to-peer model in the server.xml file, similar to the following example.

<library id="JCacheLib">
    <file name="${shared.resource.dir}/hazelcast/hazelcast.jar"/>
</library>

<httpSessionCache cacheManagerRef="CacheManager"/>

<cacheManager id="CacheManager" >
    <cachingProvider jCacheLibraryRef="JCacheLib" />
</cacheManager>

Note: To provide InstantOn support for the peer-to-peer model by using Infinispan as a JCache Provider, you must use Infinispan 12 or later. You must also enable MicroProfile Reactive Streams 3.0 or later and MicroProfile Metrics 4.0 or later in the server.xml file, in addition to the JCache Session Persistence feature.

The environment can provide vendor-specific JCache configuration properties when the server is restored from the checkpoint. The following configuration uses server list, username, and password values as variables defined in the restore environment.

<httpSessionCache libraryRef="InfinispanLib">
    <properties infinispan.client.hotrod.server_list="${INF_SERVERLIST}"/>
    <properties infinispan.client.hotrod.auth_username="${INF_USERNAME}"/>
    <properties infinispan.client.hotrod.auth_password="${INF_PASSWORD}"/>
    <properties infinispan.client.hotrod.auth_realm="default"/>
    <properties infinispan.client.hotrod.sasl_mechanism="PLAIN"/>
</httpSessionCache>

Try it now

If you’re using Maven, you can install the All Beta Features package by using:

<plugin>
    <groupId>io.openliberty.tools</groupId>
    <artifactId>liberty-maven-plugin</artifactId>
    <version>3.10.3</version>
    <configuration>
        <runtimeArtifact>
          <groupId>io.openliberty.beta</groupId>
          <artifactId>openliberty-runtime</artifactId>
          <version>24.0.0.6-beta</version>
          <type>zip</type>
        </runtimeArtifact>
    </configuration>
</plugin>

<dependency>
    <groupId>org.example.spec</groupId>
    <artifactId>exampleApi</artifactId>
    <version>7.0</version>
    <type>pom</type>
    <scope>provided</scope>
</dependency>
<dependency>
    <groupId>example.platform</groupId>
    <artifactId>example.example-api</artifactId>
    <version>11.0.0</version>
    <scope>provided</scope>
</dependency>

Or for Gradle:

buildscript {
    repositories {
        mavenCentral()
    }
    dependencies {
        classpath 'io.openliberty.tools:liberty-gradle-plugin:3.8.3'
    }
}
apply plugin: 'liberty'
dependencies {
    libertyRuntime group: 'io.openliberty.beta', name: 'openliberty-runtime', version: '[24.0.0.6-beta,)'
}

Or if you’re using container images:

FROM icr.io/appcafe/open-liberty:beta

Or take a look at our Downloads page.

If you’re using IntelliJ IDEA, Visual Studio Code or Eclipse IDE, you can also take advantage of our open source Liberty developer tools to enable effective development, testing, debugging, and application management all from within your IDE.

For more information on using a beta release, refer to the Installing Open Liberty beta releases documentation.

We welcome your feedback

Let us know what you think on our mailing list. If you hit a problem, post a question on StackOverflow. If you hit a bug, please raise an issue.

Jakarta NoSQL in Action: Switching NoSQL Databases with Ease

Tue, 14 May 2024 00:00:00 +0000

In the cloud era, switching between NoSQL solutions could be an interesting way to save resources and costs. It could also be a nightmare, especially if we’re highly coupled to a particular vendor. Certain changes could make this approach very expensive, e.g.: time spent on the change, the learning curve of a new API to use with this database, the code that will be lost, the persistence layer that needs to be replaced, etc.

This is where the flexibility of Jakarta NoSQL, with an implementation like Eclipse JNoSQL, shines.

As of March 2024, Eclipse JNoSQL supports about 30 NoSQL databases.

To explore this capability, let’s use the JNopo game introduced in blog 2 of this series.

In our scenario, let’s suppose that we need to change the JNopo’s Document NoSQL database from MongoDB, to another Document NoSQL database (Couchbase) to save money. The good thing is that because we’ve already used the Jakarta NoSQL specification to connect to our NoSQL solutions in this application, with just a few small changes we’ll be able to achieve this goal easily. Let’s take a look at the steps we need to take for this.

Table of Contents

Configuring Eclipse JNoSQL dependencies for Couchbase
Configuring a local Couchbase cluster
Key takeaways
Next steps: continuing the journey
Special thanks
References and Further Reading

Configuring Eclipse JNoSQL dependencies for Couchbase

The first step we need to take is to add the Couchbase dependency to our the pom.xml file:

<dependency>
  <groupId>org.eclipse.jnosql.databases</groupId>
  <artifactId>jnosql-couchbase</artifactId>
  <version>1.1.0</version>
</dependency>

Configuring a local Couchbase cluster

To successfully configure our new Couchbase cluster, we’ll first need to add the following content to the docker-compose.yml file:

  couchbase-db:
    image: couchbase
    container_name: couchbase-db
    ports:
      - "8091-8097:8091-8097"
      - "9123:9123"
      - "11207:11207"
      - "11210:11210"
      - "11280:11280"
      - "18091-18097:18091-18097"

After we apply these changes, we then need to initialize the container by executing the following command:

docker-compose up -d

Now, let’s configure the Couchbase cluster for this example scenario:

With the Couchbase container started, go to: http://localhost:8091/ui/index.html.
Select the Setup New Cluster option.
Define a name for the cluster.
Set root as the Admin Username.
Set 123456 as the Password.
Check I accept the terms and conditions and click the Finish With Defaults button.
Go to the Buckets section.
Create a jnopo Bucket by clicking on the Add Bucket option
Click Scopes & Collections and then click Add Collection.
Enter GameMatch as the collection name and click the Save button to complete your creation.
Now, in the Query Editor section, run the command N1QL command to create the primary index for the GameMatch collection:
```
CREATE PRIMARY INDEX primaryGameMatch ON jnopo._default.GameMatch
```

With a Couchbase cluster running, we just need to set up Eclipse JNoSQL to connect to it.

Apply the following changes into the resources/META-INF/microprofile-config.properties file:

## Couchbase
jnosql.couchbase.host=couchbase://localhost
jnosql.couchbase.user=root
jnosql.couchbase.password=123456
jnosql.document.provider=org.eclipse.jnosql.databases.couchbase.communication.CouchbaseDocumentConfiguration

The jnosql.document.provider property is required in this context because we have more than one Eclipse JNoSQL Database API for Document NoSQL implementations. You can learn more about the configurations available for Eclipse JNoSQL Database API for Couchbase in this Git repository.

That’s all! Let’s restart the Open Liberty runtime to make sure that everything is running smoothly:

On Linux/Mac machines, run the following command:
```
./mvnw liberty:dev
```
On Windows machines, run the following command:
```
mvnw.cmd liberty:dev
```

After some game matches, you should see something similar to the following images to prove that this data is now being stored in our new Couchbase database.

If you’re interesting to take a look on the finished project code developed during this challenge, clone this Git repository and navigate to the database-switching-challenge directory.

git clone https://github.com/OpenLiberty/sample-jakartaNoSQL-game.git
cd sample-jakartaNoSQL-game
cd database-switching-challenge

Key takeaways

This blog has shown just how easy it can be to switch between NoSQL solutions by using Jakarta NoSQL, bringing one more item to your utility belt that could be useful in helping you save resources and costs.

By reading this blog, you should now be familiar with:

How to set up the Couchbase database cluster for development purposes;
How to switch between NoSQL database from different vendors, in our example: switching from MongoDB to Couchbase;

Next steps: continuing the journey

Congratulations on getting this far!

This blog post is the 3rd part of a set of blog posts:

To see more sample projects, take a look at the official Eclipse JNoSQL samples repositories:

To learn more about Eclipse JNoSQL, take a look at these official repositories:

if you’re an expert on some NoSQL database that Eclipse JNoSQL doesn’t support, feel free to open an issue or a PR on the project repositories mentioned above. Except for the NoSQL solutions mentioned like MongoDB and Couchbase, all the technology used in this blog post are open-source, so, what do you think about contributing to these projects? If you don’t know how to get started to contribute, take a look at this Coffee.withJava("Contribute to JNoSQL") Youtube Series, or if you prefer, feel free to contact me! Contributing to these projects is not just with codes, you could help a lot by promoting and speaking about them wherever you go! Contributing to open-source is a great way to boost your career, and improve your skills to become an effective developer and relevant in the market! Think about that!

Special thanks

I’m bursting with gratitude and would love to give a big shout-out to my incredible Java community friends for their unwavering support throughout my journey. A special round of applause for:

Otavio Santana, you’re not just a mentor but a guiding star in my open-source journey. Your mentorship have opened doors for me to become an active open-source contributor and a proud Eclipse Foundation committer. Thank you for being such a monumental part of my journey. Also, thanks for your insightful reviews of the codes featured in this blog post.
Karina Varela, your keen eye for detail and your generosity in sharing your knowledge have enriched this content beyond measure. Your thoughtful reviews have made this content not just better, but truly curated and relevant. I’m so grateful for your contribution.
Gabriel Silva Andrade, your support and encouragement have been a constant source of inspiration for me. Your partnership at the SouJava JUG and Java community initiatives around this subject have been invaluable in shaping this content. Thank you for your unwavering support.
Fabio Franco, you were the catalyst for this wonderful opportunity, connecting me with the fantastic OpenLiberty team and offering your support throughout the publishing process of this blog post. Your belief in me and your encouragement have been invaluable. Thank you for making this possible.
And to the OpenLiberty team, thank you for opening your doors and allowing me the privilege to share and post this content that I’ve thoroughly enjoyed working on. Thanks for this opportunity.

To each of you, your support means a lot to me, and I’m deeply thankful.

References and Further Reading

Jakarta NoSQL in action: JNopo game

Mon, 13 May 2024 00:00:00 +0000

In the data-driven age of AI and cloud computing, the choice between relational or NoSQL databases crucially influences a solution’s success. The Jakarta NoSQL specification addresses this challenge by providing a standard-based, easy-to-learn framework that mirrors the familiar JPA and simplifies development across various NoSQL databases. Learn about the JNopo game and delve into how Jakarta NoSQL, together with Jakarta Data, can simplify using NoSQL databases.

After getting an overview about Jakarta NoSQL, Jakarta Data, and Eclipse JNoSQL in this blog post, we’re in a good shape to explore and understand what an actual application implementation with Jakarta NoSQL would look like, through a sample game application that relies on non-relational storage and data manipulation.

Table of Contents

Getting started: playing JNopo!
- It’s fun time: Let’s play JNopo!
The winner ranking challenge
Implementing the winner ranking
Key takeaways
Next steps: continuing the journey
Special thanks
References and further reading

Getting started: playing JNopo!

JNopo is a Java version of the famous the Rock, Paper, and Scissors game. This game consists of a battle of two players where each one chooses a move between rock, paper, or scissors. Hopefully you’re already familiar with the rules of this game, but if you are not, we’ve included some example scenarios to illustrate the game logic below. Let’s suppose that a Player A will play with a Player B and, in this case:

If Player A chooses ROCK and Player B chooses SCISSORS then Player A wins the game.
If Player A chooses PAPER and Player B chooses ROCK then Player A wins the game.
If Player A chooses SCISSORS and Player B chooses PAPER then Player A wins the game.
If Player A and Player B choose the same move, then the game is a tie and neither player wins.

In the following sequence diagram, we can illustrate the default behavior of the JNopo game:

JNopo is implemented using Jakarta EE Specifications so it’s compatible with Jakarta EE and MicroProfile runtimes. In our case, we’re using Open Liberty 23.0.0.10.

The architecture for this application is comprises two components:

The web page where the players interact with the game
The back-end where the game matches are managed

In the following image, we can see the system design of the JNopo game:

It’s fun time: Let’s play JNopo!

Before you start, this game uses the Maven Wrapper plugin, which means, you just need to have the JDK 21 or later installed in your machine to build and/or run the application.

Yeah! It’s time have fun playing JNopo!

Clone the Git repository:

git clone https://github.com/OpenLiberty/sample-jakartaNoSQL-game.git

cd sample-jakartaNoSQL-game

Navigate to the start directory. This directory contains the starting project that we’ll work through in this post.

cd start

This project is ready to run on Open Liberty. You just need to perform the following Maven Wrapper command:

For Mac or Linux:
```
./mvnw liberty:dev
```
For Windows:
```
mvnw.cmd liberty:dev
```

This will install all required dependencies and start the default server.

Now, if everything works, you can play the game by accessing the following URL address:

http://localhost:9080/jakarta-nosql-game/

To play the game locally you just need to open two browsers tabs/windows pointing to the same URL address.

The winner ranking challenge

This is where things get interesting: why not to challenge us to learn, create, and improve our knowledge and practical software development skills? That’s we’re going to do: let’s make JNopo provide a winner ranking!

This challenge is an amazing opportunity to learn and explore how to use Jakarta NoSQL and Jakarta Data to simplify NoSQL integration with Java applications.

To get a winner ranking, JNopo needs to persist the game matches results and then summarize the results composing the ranking. To expose this ranking, the application must provide a REST API like the following example:

curl -X GET \
  -H 'Accept: application/json' \
  http://localhost:9080/jakarta-nosql-game/api/playoffs/ranking

The winner ranking response is similar to the following JSON output:

{
  "data" : {
    "Max": 2,
    "Fabio": 1
  }
}

As I said, it’ll be interesting!

Implementing the winner ranking

The winner ranking requires a set of game matches results. To get that, we need to add a persistence layer to JNopo that captures and stores the game match results.

Setting up the persistence layer

Let’s add the dependencies to create the persistence layer. Our persistence layer will be implemented using Jakarta NoSQL and Jakarta Data. To implement these Jakarta EE specifications, we’ll use Eclipse JNoSQL.

Eclipse JNoSQL offers a database API collection that covers document, key-value, column and graph NoSQL databases. For now, Eclipse JNoSQL supports about 30 NoSQL databases.

For this challenge, let’s develop the persistence layer to integrate with document NoSQL databases type. Eclipse JNoSQL supports various document NoSQL databases. You can find a list of supported databases, along with their configurations and dependencies, on the GitHub repository.

Configuring project dependencies

Let’s use MongoDB as the default document database. Add the following Maven dependency into the pom.xml file of the project:

<dependency>
  <groupId>org.eclipse.jnosql.databases</groupId>
  <artifactId>jnosql-mongodb</artifactId>
  <version>1.1.0</version>
</dependency>

Once you add the appropriate dependency, you need to configure the credentials for your document database. These credentials typically include details such as the database name, host, port, and any required authentication credentials. To configure MongoDB, you can find the supported credentials properties at the Eclipse JNoSQL MongoDB Database API Configuration.

Setting up local NoSQL databases

Installing and managing databases locally requires additional efforts that we will not cover it in this blog post. We chose to use Docker Compose as the tooling for managing containers locally. Take a look at the Docker Compose Overview to learn more about this tool.

Let’s create a docker-compose.yml file into the project root directory and add the following content:

services:

  mongo:
    image: mongo
    restart: always
    environment:
      MONGO_INITDB_ROOT_USERNAME: root
      MONGO_INITDB_ROOT_PASSWORD: example
    ports:
      - 27017:27017

  mongo-express:
    image: mongo-express:1.0.0-alpha
    restart: always
    ports:
      - 8081:8081
    environment:
      ME_CONFIG_MONGODB_ADMINUSERNAME: root
      ME_CONFIG_MONGODB_ADMINPASSWORD: example
      ME_CONFIG_MONGODB_URL: mongodb://root:example@mongo:27017/

For convenience, the previous example added a mongo-express service that allows us to navigate and manage MongoDB data through a friendly web interface.

Feel free to customize the declaration of the containers in the docker-compose.yml file. For example, the database data is saved inside the container image, which means that the data will be lost if the containers are deleted.

Now, to start up the databases we just need to run the following command:

docker-compose up -d

You should now be able to access the mongo-express UI at http://localhost:8081/ :

Defining database credentials

Now that we defined the MongoDB database instance, we can set up the Eclipse JNoSQL framework correctly.

Eclipse JNoSQL uses MicroProfile Config to get the required configurations to establish the connection to the databases. We can define these properties in the resources/META-INF/microprofile-config.properties file by using environment variables. For more information about MicroProfile Config, take a look at External configuration of microservices in the Open Liberty docs.

According to the docker-compose.yml file that we have created previously, we can define the following properties:

jnosql.mongodb.host=localhost:27017
jnosql.mongodb.user=root
jnosql.mongodb.password=example
jnosql.mongodb.authentication.source=admin

Modeling data with Jakarta NoSQL

Once we add the Eclipse JNoSQL dependencies, the Jakarta NoSQL api comes together as a transient dependency to the project, allowing us to create the NoSQL entities we want.

Let’s model the GameMatch entity, which represents each game match result.

As we said before, Eclipse JNoSQL allows us to use Java Records as entities, so, let’s use this feature:

package org.jakartaee.sample.model;

import jakarta.nosql.Column;
import jakarta.nosql.Entity;
import jakarta.nosql.Id;

@Entity
public record GameMatch (
        @Id
        String id,

        @Column
        PlayerInfo playerA,

        @Column
        PlayerInfo playerB,

        @Column
        PlayerInfo winner,

        @Column
        PlayerInfo loser,

        @Column
        Boolean tied
){
}

To represent each player name and movement, let’s model such data as a PlayerInfo record class:

package org.jakartaee.sample.model;

import jakarta.nosql.Column;
import jakarta.nosql.Entity;

@Entity
public record PlayerInfo (

        @Column
        String name,

        @Column
        String movement
){
}

Data store and retrieval with Jakarta Data

Now, we’ll create a component to store and retrieve such entities from the MongoDB database. It’s common to see developers using patterns like data access object (DAO) to implement these components. That’s not a problem at all, but we use to see them making the components closer to a specific vendor database semantics, raising a vendor lock-in situation.

Nowadays, in the cloud era where we pay as we go, switching between NoSQL solutions can save resources and costs. But vendor lock-in would probably compromise this strategy. Also, other considerations come to the table when there’s a need to switch databases, such as time spent on the change, the learning curve of a new API, the code that will be lost, the persistence layer that needs to be replaced, etc. This is where the flexibility of Jakarta NoSQL shines.

Another interesting point is that DAO components tend to be closer to the database semantics than the business domain model language, requiring a high cognitive load for developers to connect the dots and fill the gaps between the technical codes and business necessities, once the code is not expressive enough, and doesn’t fit with the ubiquitous language of the business. At this point, Jakarta Data comes into play!

Coming back to our challenge, let’s create a repository component that will represents the play-offs:

package org.jakartaee.sample.model;

import jakarta.data.repository.DataRepository;
import jakarta.data.repository.Query;
import jakarta.data.repository.Repository;
import jakarta.data.repository.Save;

@Repository
public interface Playoffs extends DataRepository<GameMatch,String> {

    @Save
    GameMatch add(GameMatch gameMatch);

}

Capturing and persisting game matches

With the entity and repository already created, we need to capture and persist the results of each game match. The next obvious question is: how could we capture the required game events?

It’s a really good question! The answer is: the Events API provided by the Jakarta Context and Dependency Injection (CDI) specification!

JNopo game uses CDI Events to promote extension points, based on event publishing, to be used as needed. With that, we can implement an @Observable methods on any CDI bean to handle event objects.

See the following GameState interface. Objects that implement this interface will act as event objects:

package org.jakartaee.sample.game;

public sealed interface GameState permits
        WaitingPlayers,
        GameInvalid,
        GameAbandoned,
        GameReady,
        GameRunning,
        GameOver {
    String gameId();
}

The GameState interface is a sealed interface that defines all the supported game states. According to the sealed implementation, the event that we’re interested is the GameOver state. Such class is a record class. But it’s not just a simple record class that acts like a data transfer object (DTO), it has useful methods that return important info like:

The game identification
A tied attribute, to know whether the game ended as a tied
Player A and its moves
Player B and its moves
The winning player and its moves, if the game ended without a tie
The losing player and its moves, if the game ended without a tie

Now let`s create the GameMatchCapturer bean that captures the emitted GameOver state and stores the game match results in the database:

package org.jakartaee.sample.model;

import jakarta.enterprise.context.ApplicationScoped;
import jakarta.enterprise.event.Observes;
import jakarta.inject.Inject;
import org.jakartaee.sample.game.GameOver;

@ApplicationScoped
public class GameMatchCapturer {

    public void captureAndPersist(@Observes GameOver gameOver){
        // put the persistence logic here...
    }

}

At this point, let’s instantiate a new GameMatch entity instance, populate it from GameOver data and then store it into the database by using the Playoffs component.

The required Playoff component, which is a repository implementation provided Eclipse JNoSQL, will be injected by CDI using the @Inject and @Database(DOCUMENT) annotations:

package org.jakartaee.sample.model;

import jakarta.enterprise.context.ApplicationScoped;
import jakarta.enterprise.event.Observes;
import jakarta.inject.Inject;
import org.eclipse.jnosql.mapping.Database;
import org.eclipse.jnosql.mapping.DatabaseType;
import org.jakartaee.sample.game.GameOver;

@ApplicationScoped
public class GameMatchCapturer {

    @Inject
    @Database(DatabaseType.DOCUMENT)
    Playoffs playoffs;

    public void captureAndPersist(@Observes GameOver gameOver){

            var gameMatch  = new GameMatch(
                    gameOver.gameId(),
                    PlayerInfo.of(gameOver.playerAInfo()),
                    PlayerInfo.of(gameOver.playerBInfo()),
                    gameOver.winnerInfo().map(PlayerInfo::of).orElse(PlayerInfo.NOBODY),
                    gameOver.winnerInfo().map(PlayerInfo::of).orElse(PlayerInfo.NOBODY),
                    gameOver.isTied()
            );

            playoffs.add(gameMatch);
    }

}

Now, let’s start the Open Liberty runtime to figure out if the game match results are being stored on the MongoDB.

On Linux/Mac machines, run the following command:
```
./mvnw liberty:dev
```
On Windows machines, run the following command:
```
mvnw.cmd liberty:dev
```

After some game matches, we can confirm the persistence of the game matches into the database by looking at Mongo Express running on http://localhost:8081 :

Or, if you’re a command-line practitioner, you can check the data by using the mongosh cli:

docker exec -it finish-mongo-1 mongosh -u root -p example --authenticationDatabase admin jnopo

Once connected, you can run mongo commands:

Getting the number of stored documents:
```
jnopo> db.GameMatch.countDocuments()
3
```

Getting the stored documents list:

jnopo> db.GameMatch.find()
[
  {
    _id: '2f42cf9e-f99c-44e5-bda8-7707da2579a3',
    tied: true,
    winner: { name: '', movement: '' },
    playerA: { name: 'Max', movement: 'ROCK' },
    playerB: { name: 'Ghost', movement: 'ROCK' },
    loser: { name: '', movement: '' }
  },
  {
    _id: 'c425815c-2aaf-4caa-a975-8e8089f0a0ce',
    tied: false,
    winner: { name: 'Max', movement: 'PAPER' },
    playerA: { name: 'Ghost', movement: 'ROCK' },
    playerB: { name: 'Max', movement: 'PAPER' },
    loser: { name: 'Max', movement: 'PAPER' }
  },
  {
    _id: 'bb7e7cd5-f8fe-4db1-9e90-44ecd433b4de',
    tied: false,
    winner: { name: 'Ghost', movement: 'ROCK' },
    playerA: { name: 'Ghost', movement: 'ROCK' },
    playerB: { name: 'Max', movement: 'SCISSORS' },
    loser: { name: 'Ghost', movement: 'ROCK' }
  }
]

Great! JNopo is storing the game match results as expected! It’s time to create the winner ranking and then expose it though a restful endpoint: http://localhost:9080/jakarta-nosql-game/api/playoffs/ranking .

Exposing the winner ranking

Collecting and storing the game matches enables us to implement the winner ranking feature.

Let’s implement the Ranking class to represent any ranking on the JNopo application.

The Ranking creation requires the data from the Playoffs component. In order to avoid to create a new layer to keep the logic of the ranking creation, I decided to use a simple approach: a simple static factory method on the Ranking class itself.

Firstly, Playoffs needs to provide a method to retrieve the non-tied game results:

package org.jakartaee.sample.model;

import jakarta.data.repository.DataRepository;
import jakarta.data.repository.Query;
import jakarta.data.repository.Repository;
import jakarta.data.repository.Save;

import java.util.stream.Stream;

@Repository
public interface Playoffs extends DataRepository<GameMatch,String> {

    @Save
    GameMatch add(GameMatch gameMatch);

    @Query("select * from GameMatch where tied=false")
    Stream<GameMatch> nonTiedGameMatches();

}

JNoSQL offers a simple query language that is pretty similar to SQL. However, it’s not a complete SQL implementation and some aggregation and functions are not available.

Regarding the aggregation process that evolves the ranking logic creation, we used to see developers delegating this aggregation logic to the DBMS and, depending on the persistence mechanism, it should be the best approach. For now, the grouping projection functions like we have with Jakarta Persistence is not available on the Jakarta NoSQL. However, in the future, such capabilities might be available.

In order to keep our implementation free of vendor lock-in, I decided to implement the aggregation process by using the Stream API. I added comments on the code to help you to understand the implemented logic.

package org.jakartaee.sample.model;

import java.util.Collection;
import java.util.Comparator;
import java.util.LinkedHashMap;
import java.util.Map;
import java.util.stream.Collectors;

public record Ranking(Map<String, Integer> data) {
    public static Ranking winnerRanking(Playoffs playoffs) {

        var data =
                // getting the game matches that are not tied
                playoffs.nonTiedGameMatches()
                // grouping by winner's name and summarize by game match
                .collect(Collectors.groupingBy(
                        g -> g.winner().name(),
                        Collectors.collectingAndThen(Collectors.toList(), Collection::size)))
                .entrySet()
                .stream()
                // sorting the results by number of game match in descending order
                .sorted(Map.Entry.comparingByValue(Comparator.reverseOrder()))
                // collecting as a LinkedHashMap to keep the sorted items
                .collect(Collectors.toMap(
                        Map.Entry::getKey,
                        Map.Entry::getValue,
                        (e1, e2) -> e1, LinkedHashMap::new));

        return new Ranking(data);
    }
}

Now, let make this ranking be accessible to our model. As the ranking needs the data from the Playoffs component, why not to put the ranking creation on the Playoffs interface? That’s we’re going to do! It is possible since the Java 8:

package org.jakartaee.sample.model;

import jakarta.data.repository.DataRepository;
import jakarta.data.repository.Query;
import jakarta.data.repository.Repository;
import jakarta.data.repository.Save;

import java.util.stream.Stream;

@Repository
public interface Playoffs extends DataRepository<GameMatch,String> {

    @Save
    GameMatch add(GameMatch gameMatch);

    @Query("select * from GameMatch where tied=false")
    Stream<GameMatch> nonTiedGameMatches();

    default Ranking winnerRanking(){
       return Ranking.winnerRanking(this);
    }
}

It looks like we’re getting closer to our goal!

Following the challenge requirements, let’s create the resource component that will expose the winner ranking.

Firstly, let’s create the RestApplication class to define the URL dedicated to restful endpoints:

package org.jakartaee.sample.resources;

import jakarta.ws.rs.ApplicationPath;
import jakarta.ws.rs.core.Application;

@ApplicationPath("/api")
public class RestApplication extends Application {

}

Now, any URL under /api will be handled by the Jakarta Restful Web Services implementation available in our runtime environment.

Next step: let’s implement the PlayoffsResource resource. This component will expose an HTTP GET endpoint for the /api/playoffs/ranking URL:

package org.jakartaee.sample.resources;

import jakarta.inject.Inject;
import jakarta.ws.rs.Consumes;
import jakarta.ws.rs.GET;
import jakarta.ws.rs.Path;
import jakarta.ws.rs.Produces;
import jakarta.ws.rs.core.MediaType;
import org.eclipse.jnosql.mapping.Database;
import org.eclipse.jnosql.mapping.DatabaseType;
import org.jakartaee.sample.model.Playoffs;
import org.jakartaee.sample.model.Ranking;

@Path("/playoffs")
@Consumes({MediaType.APPLICATION_JSON})
@Produces({MediaType.APPLICATION_JSON})
public class PlayoffsResource {

    @Inject
    @Database(DatabaseType.DOCUMENT)
    Playoffs playoffs;

    @GET
    @Path("/ranking")
    public Ranking getRanking() {
        return playoffs.winnerRanking();
    }
}

It’s time to test everything! Let’s restart the Open Liberty runtime:

On Linux/Mac machines, run the following command:
```
./mvnw liberty:dev
```
On Windows machines, run the following command:
```
mvnw.cmd liberty:dev
```

Open Liberty provides amazing tooling to help during develop Jakarta EE / MicroProfile applications. When dev mode is running, we can use some HTTP addresses to test and explore the capabilities offered by this amazing Jakarta EE/MicroProfile runtime:

[INFO] [AUDIT   ] CWWKT0016I: Web application available (default_host): http://localhost:9080/openapi/
[INFO] [AUDIT   ] CWWKT0016I: Web application available (default_host): http://localhost:9080/health/
[INFO] [AUDIT   ] CWWKT0016I: Web application available (default_host): http://localhost:9080/jwt/
[INFO] [AUDIT   ] CWWKT0016I: Web application available (default_host): http://localhost:9080/metrics/
[INFO] [AUDIT   ] CWWKT0016I: Web application available (default_host): http://localhost:9080/openapi/ui/
[INFO] [AUDIT   ] CWWKT0016I: Web application available (default_host): http://localhost:9080/ibm/api/
[INFO] [AUDIT   ] CWWKT0016I: Web application available (default_host): http://localhost:9080/jakarta-nosql-game/

Let’s focus on two of these URLs:

http://localhost:9080/jakarta-nosql-game/ is the URL of the application that we can use locally.
http://localhost:9080/openapi/ui/ is the Swagger UI interface that Open Liberty offers out-of-the-box, facilitating the rest endpoint testing via browser.

If you’re a command-line practitioner, you can check the data by using the curl command:

curl -X 'GET' \
  'http://localhost:9080/jakarta-nosql-game/api/playoffs/ranking' \
  -H 'accept: application/json' | jq

{
  "data": {
    "Max": 3,
    "Ghost": 1
  }
}

Congratulations if you made it this far!

Now, JNopo is providing a winner ranking!

If you’re interested to take a look on the finished project code version developed during this challenge, clone this Git repository and then navigate to the winner-ranking-challenge directory.

git clone https://github.com/OpenLiberty/sample-jakartaNoSQL-game.git
cd sample-jakartaNoSQL-game
cd winner-ranking-challenge

Key takeaways

This challenge was an amazing opportunity to learn not just about Jakarta NoSQL and Jakarta Data to simplify the NoSQL integration with Java applications but also to explore new development approaches using interesting Java features.

What we got by doing these challenges:

A practical example that uses:
- Sealed classes (final feature since Java 17)
- Pattern Matching for Instanceof (final feature since Java 16)
- Pattern Matching for Switch (final feature since Java 21)

What we learned from them:

How to configure Eclipse JNoSQL to allow us to work with Jakarta NoSQL and Jakarta Data in a Jakarta EE / MicroProfile project
How to work with Jakarta NoSQL to create entities pretty similar to Jakarta Persistence approach
How to create repositories with Jakarta Data, the newest Jakarta EE Specification that will be available in the Jakarta EE 11

Next steps: continuing the journey

Congratulations on getting this far!

In the next blog post, a new challenge is introduced: Switching NoSQL Databases with Ease! Stay tuned!

This blog post is the 2nd blog in a 3-part blog series. You can check out the other blogs in this series through the links below:

Simplifying NoSQL Database Integration with Jakarta NoSQL;

To see more sample projects, take a look at the official Eclipse JNoSQL samples repositories:

To learn more about Eclipse JNoSQL, take a look at these official repositories:

if you’re an expert on some NoSQL database that Eclipse JNoSQL doesn’t support, feel free to open an issue or a PR on these project repositories.

Except for the NoSQL solutions like MongoDB and Couchbase, all the technology used in this blog post is open-source, so, what do you think about contributing to these projects? If you don’t know how to get started to contribute, take a look at this Coffee.withJava("Contribute to JNoSQL") Youtube Series, or if you prefer, feel free to contact me. Contributing to these projects is not just code, you could help a lot by promoting and speaking about them wherever you go! Contributing to open-source is a great way to boost your career and improve your skills to become an effective developer and relevant in the market! Think about that!

Special thanks

I’m bursting with gratitude and would love to give a big shout-out to my incredible Java community friends for their unwavering support throughout my journey. A special round of applause for:

Otavio Santana, you’re not just a mentor but a guiding star in my open-source journey. Your mentorship have opened doors for me to become an active open-source contributor and a proud Eclipse Foundation committer. Thank you for being such a monumental part of my journey. Also, thanks for your insightful reviews of the codes featured in this blog post.
Karina Varela, your keen eye for detail and your generosity in sharing your knowledge have enriched this content beyond measure. Your thoughtful reviews have made this content not just better, but truly curated and relevant. I’m so grateful for your contribution.
Gabriel Silva Andrade, your support and encouragement have been a constant source of inspiration for me. Your partnership at the SouJava JUG and Java community initiatives around this subject have been invaluable in shaping this content. Thank you for your unwavering support.
Fabio Franco, you were the catalyst for this wonderful opportunity, connecting me with the fantastic OpenLiberty team and offering your support throughout the publishing process of this blog post. Your belief in me and your encouragement have been invaluable. Thank you for making this possible.
And to the OpenLiberty team, thank you for opening your doors and allowing me the privilege to share and post this content that I’ve thoroughly enjoyed working on. Thanks for this opportunity.

To each of you, your support means a lot to me, and I’m deeply thankful.

References and further reading

Simplifying NoSQL database integration with Jakarta NoSQL

Fri, 10 May 2024 00:00:00 +0000

In the data-driven age of AI and cloud computing, choosing the right data storage strategy directly impacts the success of a solution. We currently rely on two major data storage approaches: relational and NoSQL databases. When it comes to working with relational databases, the Java Persistence API (JPA) specification is a robust and widely adopted API. In contrast, the crowded landscape of NoSQL databases opens a large set of integration options for developers, who often find themselves learning at the mercy of vendor-specific solutions instead of relying on standards.

Most importantly, how we define data storage and code design either facilitates or hinders the project’s maintainability, performance, scalability, and ability to change databases later on.

Fortunately, Java developers who embrace NoSQL solutions no longer need to worry about many of these concerns. The Jakarta NoSQL specification offers a well-defined, standards-based implementation with a low learning curve and familiar coding APIs, thanks to its similarities with the widely-adopted JPA specification.

Join us in this comprehensive article, as we explore Jakarta NoSQL and how this specification can simplify developers' lives, no matter which NoSQL database their applications use!

Table of Contents

Understanding NoSQL databases
Key differences: SQL vs NoSQL
Exploring NoSQL database types
Challenges of NoSQL integration
Introducing Jakarta NoSQL and Jakarta Data
Next steps: continuing the journey
Special Thanks
References and Further Reading

Understanding NoSQL databases

The market has different views on the meaning of the name "NoSQL"; while some believe it is an acronym for "Not Only SQL", others understand it as "Non-SQL" or "Not relational". Regardless of these different interpretations, there’s an undeniable aspect of this solution: NoSQL databases are fundamentally different in terms of data storage and management when compared to SQL.

Key differences: SQL vs NoSQL

So what are the differences between these two? In the following table, we can see the key differences between SQL and NoSQL:

Description	SQL Databases	NoSQL Databases
Data Storage	Use tabular relations to store and retrieve data	Provide mechanisms for retrieving and storing unstructured and semi-structured data (non-relational)
Schema	Predefined schemas	No predefined schemas
Scalability	Vertical scalability (scale up)	Horizontal scalability (scale out)
Data Distribution	Data distributed across fewer servers	Data distributed across many servers
Suitability	Better suited for smaller, structured datasets	Well-suited for handling large and growing datasets
Industry Adoption	Traditionally used in many industries	Gaining popularity in industries like finance and streaming

Description

SQL Databases

NoSQL Databases

Data Storage

Use tabular relations to store and retrieve data

Provide mechanisms for retrieving and storing unstructured and semi-structured data (non-relational)

Schema

Predefined schemas

No predefined schemas

Scalability

Vertical scalability (scale up)

Horizontal scalability (scale out)

Data Distribution

Data distributed across fewer servers

Data distributed across many servers

Suitability

Better suited for smaller, structured datasets

Well-suited for handling large and growing datasets

Industry Adoption

Traditionally used in many industries

Gaining popularity in industries like finance and streaming

Now that we’ve explored the fundamental differences between SQL and NoSQL databases, let’s focus more on NoSQL databases. The next section looks at the different types of NoSQL databases, each designed to solve specific problems with unique data models and architectures.

Exploring NoSQL database types

In the NoSQL space, each database type solves different needs. The following overview examines the most popular non-relational storage approaches: key-value, document, column, and graph databases .

Key-value databases

Key-value databases are the simplest of the NoSQL database types. Data is stored as a collection of key-value pairs. It’s ideal for getting information when you know the specific key, like finding a contact in your phone by their name. The structure resembles the Java java.util.Map API, where values are mapped to keys.

Key-value databases are often used for caching, session management, and message queues.

Examples of vendors currently offering key-value solutions include Amazon DynamoDB, Redis, Hazelcast, and Memcached. The last three are open source technologies.

Document databases

Document databases are designed to store, retrieve, and manage documents with minimally defined structures, such as XML and JSON formats. A document without a predefined structure is a data model that can be composed of multiple fields to hold different data types.

Since it’s possible to design models that hold documents inside other documents, Domain-Driven Design (DDD) practitioners can leverage document aggregates to manage their derived entities in a hierarchical structure.

Document databases are well-suited for managing unstructured data, such as user profiles, product catalogs, or content management systems.

Key vendors providing document database solutions include MongoDB, Couchbase, Elastic, and Oracle NoSQL Database.

Column Databases

Column databases, also known as column-oriented or wide-column databases, store data as columns instead of rows, in contrast to traditional relational databases. This approach is a differentiator across other types, as it’s an efficient way to handle large amounts of data and run performant complex queries.

This type is designed and optimized for storing large amounts of structured, semi-structured, and unstructured data with a flexible schema, and supports high levels of concurrency and scalability.

Wide-column databases are often used for analytics, content management, and data warehousing.

Examples of column databases include Apache HBase, Apache Cassandra, Scylla, Azure Cosmos DB, and many others. The first two mentioned here are open source technologies.

Graph databases

The graph NoSQL database is optimized for storing and querying data with complex relationships. In this approach, data is managed as a graph, where entities can be represented as nodes and edges, resulting in performant management of complex relationship and hierarchies.

The graph data resembles the graph of objects in the object-oriented programming (OOP) paradigm. Graph NoSQL database solutions are a good fit for scenarios that require fast querying of highly interconnected data, such as social networks, recommendation engines, and fraud detection systems.

Graph databases available today are Neo4J, Arango DB, OrientDB, and JanusGraph, among others. The last one mentioned is an open source technology.

Challenges of NoSQL integration

Modern solutions frequently require the capabilities and benefits of different types of NoSQL databases, therefore, we should be able to work with multiple NoSQL solutions, coming from different vendors. Having said that, we can expect to face challenges such as:

A high cognitive load when choosing a NoSQL database solutions
A significant learning curve derived from usage of different database APIs
Extra time invested on changing and maintaining the existing codebase
Potential increase in complexity when onboarding new developers to the team

Furthermore, in the cloud era of consumption-based pricing models, we must consider ways to deliver solutions with efficient resource consumption for costs reduction. This is how potential discussions arise, opening the possibility to consider changes of the underlying database used by existing applications.

In addition to these challenges, a solution based on NoSQL must be flexible and designed with a concise isolation between business logic and the underlying persistence layer, given the high probability of changes being made to both.

As of February 2024, the DB-Engines Ranking, an initiative that aims to list and rank DBMS by popularity, there are over 180 non-relational/NoSQL databases available in the market.

To solve these challenges, we can refer to a not-so-distant past, when we faced a similar challenge with relational databases and Java integration. The Java Database connectivity (JDBC) specification standardized the way Java integrates with relational databases. To better align it with the OOP paradigm, the ORM pattern was popularized and the Jakarta Persistence specification was created to facilitate working with different relational databases engines and vendors.

So, based on this background context about solutions with Jakarta Persistence, wouldn’t it be interesting to have a similar solution and APIs to work with NoSQL?

Say hello to Jakarta NoSQL and Jakarta Data!

Introducing Jakarta NoSQL and Jakarta Data

These are specifications proposing a simpler NoSQL integration and abstract aspects of database vendors, allowing for developers to manipulate data with intuitive and developer-friendly APIs.

Jakarta NoSQL

Jakarta NoSQL is a Jakarta EE specification designed to easily integrate Java and NoSQL databases. It uses common annotations and specific APIs for key-value, column, and document databases.

Jakarta Data

The Jakarta Data specification, part of Jakarta EE, proposes a unified API for simplified data access across different types of databases, from relational to NoSQL databases.

Jakarta Data achieves its goal by introducing concepts like repositories and custom query methods, improving the developer experience when using data retrieval and manipulation APIs.

Jakarta Data is planned for inclusion in Jakarta EE 11

Eclipse JNoSQL: A reference implementation

A Jakarta EE specification can’t solve the problem by itself - it becomes consumable through an implementation.

Each Jakarta EE specification has at least one implementation. The existence of an implementation proves the proposed specification is achievable and can be developed by interested third-parties. This is when companies and communities actively start providing their own implementations, empowering the Jakarta EE developers and ecosystem with a diverse and powerful toolset.

Example of reference implementations (RI) are Hibernate for Jakarta Persistence 3.1 specification; Jersey for Jakarta RESTFul Web Services 3.1 specification; Glassfish for Jakarta Servlet 6.0 specification; Weld for Jakarta Context And Dependency Injection (CDI) 4.0 specification; and so on…

Eclipse JNoSQL is a compatible implementation of the Jakarta NoSQL and Jakarta Data specifications, a framework that streamlines the integration of Java applications with relational and NoSQL databases. Powered by the Jakarta Contexts and Dependency Injection (CDI) specification, it is compatible with Jakarta EE and MicroProfile compatible solutions.

Eclipse JNoSQL covers four NoSQL database types: key-value, column, document and graph.

Currently, the Jakarta NoSQL doesn’t define an API for Graph database types but Eclipse JNoSQL provides a Graph template to explore the specific behavior of this database type by using Apache TinkerPop as a communication layer.

As of March 2024, Eclipse JNoSQL supports about 30 NoSQL databases.

Why Eclipse JNoSQL?

In the following code samples, note the APIs similarities and differences across different vendors. All samples demonstrate a commonly used functionality for document databases: a document creation and the addition of a property to that document:

var document = new Document();
document.append(name, value);

var baseDocument = new BaseDocument();
baseDocument.addAttribute(name, value);

var jsonObject = JsonObject.create();
jsonObject.put(name, value);

var document = new ODocument("collection");
document.field(name, value);

With Eclipse JNoSQL, developers can use a common API to integrate with different database types, free of vendor lock-in and with a low cognitive load during learning phases. For example, using the Document API, it’s possible to switch between MongoDB and ArangoDB as needed, based on convention over configuration (CoC).

var entity = CommunicationEntity.of("collection");
entity.add(name, value);

Check out some of the Jakarta NoSQL annotations:

import jakarta.nosql.Entity;
import jakarta.nosql.Id;
import jakarta.nosql.Column;

@Entity
public class Book {

    @Id
    private String isbn;

    @Column
    private String title;

    @Column
    private String author;

    @Convert(YearConverter.class)
    @Column
    private Year year;

}

When using Java 17+, Eclipse JNoSQL allows the usage of Java Records as entities:

import jakarta.nosql.Entity;
import jakarta.nosql.Id;
import jakarta.nosql.Column;

@Entity
public record Book(@Id String isbn,
                   @Column("title") String title,
                   @Column("author") String author,
                   @Convert(YearConverter.class) @Column("year") Year year,
                   @Column("edition") int edition) {

}

Last but not least, Eclipse JNoSQL, as a Jakarta Data implementation, allows us to create repositories, enabling domain-driven development (DDD) capabilities through the usage of the repository pattern. This approach helps developers bring the code closer to the business (domain-centric) instead of working with database semantics.

import jakarta.data.page.Page;
import jakarta.data.page.PageRequest;
import jakarta.data.repository.Delete;
import jakarta.data.repository.Repository;
import jakarta.data.repository.DataRepository;
import jakarta.data.repository.Query;
import jakarta.data.repository.Param;
import jakarta.data.repository.Save;

@Repository
public interface Garage extends DataRepository<Car,String>{

    @Save
    Car park(Car car);

    @Delete
    Car unPark(Car car);

    @Query("select * from Car where driver.name = @name")
    Set<Car> findByDriver(@Param("name") String name);

    Page<Car> findByColor(Color color, PageRequest pageRequest);

}

What to expect from Eclipse JNoSQL

Beyond being a Jakarta NoSQL and Jakarta Data implementation, Eclipse JNoSQL supports the following goals:

Increase productivity performing common NoSQL operations
Use of convention over configuration
Rich object mapping integrated with contexts and dependency injection (CDI)
Java-based query and fluent API
Persistent lifecycle events
Low-level mapping using standard NoSQL APIs
Specific template API to each NoSQL category
Annotation-oriented using JPA-like naming when it makes sense
Extensible to explore the particular behavior of a NoSQL database
Explore the popularity of Apache TinkerPop in Graph API

Next steps: continuing the journey

Congratulations on getting this far!

After getting an overview of Jakarta NoSQL, Jakarta Data, and the Eclipse JNoSQL, I invite you to explore a hands-on approach to these tools, managing and querying data from NoSQL databases and switching between NoSQL databases as needed.

This blog post is the 1st part of a set of blog posts, keep you eyes out for these follow-ups coming soon:

Jakarta NoSQL in Action: JNopo Game;
Jakarta NoSQL in Action: Switching NoSQL Databases with Ease

To see some sample projects, take a look at the official Eclipse JNoSQL samples repositories:

To learn more about Eclipse JNoSQL, take a look at these official repositories:

If you’re an expert on some NoSQL database that Eclipse JNoSQL doesn’t support, feel free to open an issue or a PR in these project repositories.

Except for previously mentioned NoSQL solutions like MongoDB and Couchbase, all the technology used in this blog post is open-source. So, what do you think about contributing to these projects? If you don’t know how to get started, take a look at this Coffee.withJava("Contribute to JNoSQL") Youtube Series, or if you prefer, feel free to contact me! Contributing to these projects is not just code, you could help a lot by promoting and speaking about them wherever you go! Contributing to open-source is a great way to boost your career, and improve your skills to become an effective developer and relevant in the market! Think about that!

Special Thanks

I’m bursting with gratitude and would love to give a big shout-out to my incredible Java community friends for their unwavering support throughout my journey. A special round of applause for:

Otavio Santana, you’re not just a mentor but a guiding star in my open-source journey. Your mentorship have opened doors for me to become an active open-source contributor and a proud Eclipse Foundation committer. Thank you for being such a monumental part of my journey. Also, thanks for your insightful reviews of the codes featured in this blog post.
Karina Varela, your keen eye for detail and your generosity in sharing your knowledge have enriched this content beyond measure. Your thoughtful reviews have made this content not just better, but truly curated and relevant. I’m so grateful for your contribution.
Gabriel Silva Andrade, your support and encouragement have been a constant source of inspiration for me. Your partnership at the SouJava JUG and Java community initiatives around this subject have been invaluable in shaping this content. Thank you for your unwavering support.
Fabio Franco, you were the catalyst for this wonderful opportunity, connecting me with the fantastic OpenLiberty team and offering your support throughout the publishing process of this blog post. Your belief in me and your encouragement have been invaluable. Thank you for making this possible.
And to the OpenLiberty team, thank you for opening your doors and allowing me the privilege to share and post this content that I’ve thoroughly enjoyed working on. Thanks for this opportunity.

To each of you, your support means a lot to me, and I’m deeply thankful.

References and Further Reading

Jakarta EE 11 previews and InstantOn support for IBM MQ in 24.0.0.5-beta

Tue, 07 May 2024 00:00:00 +0000

The 24.0.0.5-beta release introduces previews for several Jakarta EE 11 features, including Jakarta Contexts and Dependency Injection 4.1, Jakarta Concurrency 3.1, Jakarta Data 1.0, Jakarta Expression Language 6.0, Jakarta Pages 4.0, and Jakarta Servlet 6.1. This release also includes support for using InstantOn with IBM MQ messaging.

The Open Liberty 24.0.0.5-beta includes the following beta Jakarta EE 11 features (along with all GA features):

Jakarta CDI 4.1
Jakarta Concurrency 3.1
Jakarta Data 1.0 (Milestone 4)
Jakarta Expression Language 6.0
Jakarta Pages 4.0
Jakarta Servlet 6.1

In 24.0.0.5-beta, you can also use IBM® MQ messaging with InstantOn support.

Jakarta CDI 4.1

CDI allows objects to be bound to lifecycle contexts, to be injected, to be associated with interceptors and decorators, and to interact in a loosely coupled fashion by firing and observing events. Highlights of CDI 4.1 include the ability for interceptors to inspect the annotations that are used to bind them. This update also brings in new Jakarta EE 11 versions of the Jakarta Annotations and Jakarta Interceptors APIs.

Retrieve interceptor binding information

Support is added to allow interceptors to retrieve and inspect the annotations that are used to bind them. Interceptors can now call InvocationContext.getInterceptorBindings() or one of the related methods to retrieve the annotations so that they can read values from them. This capability is particularly useful when some of the fields of an interceptor binding annotation are annotated with @Nonbinding. These fields are not used to restrict which interceptor is bound and can now be read by the interceptor when the interceptor method is called.

For example, a binding annotation for a logging interceptor might look like this:

@InterceptorBinding
public @interface Logged {
    @Nonbinding String value();
}

This annotation might be applied to a method on a managed bean like this:

@Logged("myName")
public void myMethod() {
   // ....
}

Then, an interceptor like this can read the myName value from the annotation and include it in the log message:

@Interceptor
@Logged("")
public class LoggedInterceptor {

    private static final Logger LOG = Logger.getLogger(LoggedInterceptor.class.getName());

    @AroundInvoke
    public Object intercept(InvocationContext ctx) throws Exception {
        Logged binding = ctx.getInterceptorBinding(Logged.class);
        LOG.info("Method called: " + binding.value());
        return ctx.proceed();
    }
}

The new methods added to InvocationContext make it easier to retrieve the annotations. These methods return the correct binding annotations whether they’re applied to the class or the method and reflect any changes that are made to the annotations by a CDI extension.

Method invoker support

Support is added for extensions to create method invokers, which are used to call a method on a CDI-managed bean indirectly and can support looking up the object instance and the method arguments from CDI. This feature is intended for people who want to build frameworks that build on or integrate with CDI.

For more information on how to create and use an Invoker, see the CDI specification blog.

Deprecated methods in BeanManager

The BeanManager.getELResolver and BeanManager.wrapExpressionFactory methods are deprecated and will be removed in the next major version so that the CDI API won’t need to depend on the Expression Language (EL) API. The same methods are added to ELAwareBeanManager, which extends BeanManager and lives in a new API jar.

These methods were mostly used by EL implementations, but any users who want to continue using these methods must switch to using ELAwareBeanManager and include the new API artifact in their dependencies. For example, by adding it to their maven pom.xml file:

<dependency>
    <groupId>jakarta.enterprise</groupId>
    <artifactId>jakarta.enterprise.cdi-el-api</artifactId>
    <scope>provided</provided>
    <version>4.1.0</version>
</dependency>

in this beta, ELAwareBeanManager cannot be injected directly, but a BeanManager can be injected and then cast to an ELAwareBeanManager. This limitation will be fixed before release.

Remove references to Managed Beans specification

Jakarta EE 11 does not include the Managed Beans specification, which was separate from the CDI specification but did many of the same things. As a result, the associated @ManagedBean annotation is removed from the Jakarta Annotations API.

Changes to EE integration

The parts of the CDI specification that define how CDI integrates with other Jakarta EE technologies moved into the Jakarta EE 11 Platform, Web Profile, and Core Profile specifications. This has no effect on users, but if you use the CDI specification as a documentation reference, you will find that some parts of it are now in the Plaform, Web Profile and Core Profile specifications instead.

To use the CDI 4.1 feature, add cdi-4.1 to your server.xml file:

<featureManager>
  <feature>cdi-4.1</feature>
</featureManager>

Further references:

Jakarta Concurrency 3.1

Jakarta Concurrency allows applications to use concurrency while maintaining the benefits of running on a Jakarta EE runtime. Jakarta Concurrency 3.1 is the new version for the upcoming Jakarta EE 11 release, and it adds support for new features of the latest Java SE releases as well as some usability improvements.

The new features in Jakarta Concurrency 3.1 are improved support for the Java Flow (Reactive Streams) APIs and the use of virtual threads in managed executors and managed thread factories. Support is also included for using @Inject in place of @Resource and the option to run asynchronous methods on a schedule by using the new @Schedule annotation.

To support the Flow APIs, ContextService has two new methods, contextualSubscriber, which provides context in a Flow.Subscriber, and contextualProcessor, which provides context in a Flow.Processor. These new methods allow for context in a flow when using a Flow.Publisher, which does not allow configuring a ManagedExecutor.

publisher.subscribe(contextService.contextualSubscriber(subscriber));

Virtual threads are available in Jakarta Concurrency 3.1 by specifying virtual = true on a ManagedExecutorDefinition, ManagedScheduledExecutorDefinition, or ManagedThreadFactory instance. Virtual threads are a new feature of Java 21, so when running on Java 17 and ‘virtual = true’ is specified, platform threads are provided instead of virtual threads.

@ManagedExecutorDefinition(name = "java:module/concurrent/virtual-executor",
                           virtual = true)

The new @Schedule annotation allows asynchronous methods to run on a schedule. In this example, after the method is called, it runs asynchronously at 10 AM on every day of every month where the day of the week is a Monday, Wednesday, or Friday, according to the provided cron string.

@Asynchronous(runAt = @Schedule(cron = "0 10 * * MON,WED,FRI", zone = "America/Chicago"))
void runAt10MWF() {
    ...
    if (neverRunAgain)
        Asynchronous.Result.complete(null);
}

To try out Jakarta Concurrency 3.1, check out the sample application.

To use this feature, add the following code to your server.xml file:

<featureManager>
     <feature>concurrent-3.1</feature>
</featureManager>

Jakarta Data (Milestone 4)

Jakarta Data is a new Jakarta EE specification being developed in the open that aims to standardize the popular Data Repository pattern across various providers. Open Liberty includes the Jakarta Data 1.0 Milestone 4 release, which adds the Jakarta Data Query Language (JDQL) and enhances the Static Metamodel.

Jakarta Data 1.0 Milestone 4 introduces Jakarta Data Query Language (JDQL), which is a subset of Jakarta Persistence Query Language (JPQL). JDQL allows basic comparison and update operations on a single entity (an entity identifier variable is not used), as well as the ability to perform deletion. Find operations in JDQL consist of SELECT, FROM, WHERE, and ORDER BY clauses, all of which are optional. The static metamodel, which allows for more type-safe usage, is simplified in Milestone 4 to allow all fields to be pre-initialized. To use these capabilities, you need an Entity and a Repository.

annotated with jakarta.persistence.Entity and related annotations from Jakarta Persistence
a Java class without entity annotations, in which case the primary key is inferred from an entity property that is named id or ending with Id and an entity property that is named version designates an automatically incremented version column.

The following example shows a simple entity:

@Entity
public class Product {
    @Id
    public long id;

    public boolean isDiscounted;

    public String name;

    public float price;

    @Version
    public long version;
}

The following example shows a repository that defines operations that relate to the entity. Your repository interface can inherit from built-in interfaces such as BasicRepository and CrudRepository to gain various general-purpose repository methods for inserting, updating, deleting, and querying for entities. You can add methods to further customize it.

@Repository(dataStore = "java:app/jdbc/my-example-data")
public interface Products extends BasicRepository<Product, Long> {
    @Insert
    Product add(Product newProduct);

    // query-by-method name pattern:
    List<Product> findByNameIgnoreCaseContains(String searchFor, Order<Product> orderBy);

    // parameter based query that does not require -parameters because it explicitly specifies the name
    @Find
    Page<Product> find(@By("isDiscounted") boolean onSale,
                       PageRequest<Product> pageRequest);

    // find query in JDQL that requires compilation with -parameters to preserve parameter names
    @Query("SELECT price FROM Product WHERE id=:productId")
    Optional<Float> getPrice(long productId);

    // update query in JDQL:
    @Query("UPDATE Product SET price = price - (?2 * price), isDiscounted = true WHERE id = ?1")
    boolean discount(long productId, float discountRate);

    // delete query in JDQL:
    @Query("DELETE FROM Product WHERE name = ?1")
    int discontinue(String name);
}

Observe that the repository interface includes type parameters in PageRequest<Product> and Order<Product>. These parameters help ensure that the page request and sort criteria are for a Product entity rather than some other entity. To accomplish this, you can optionally define a static metamodel class for the entity (or various IDEs might generate one for you after the 1.0 specification is actually released). Here is one that can be used with the Product entity:

@StaticMetamodel(Product.class)
public class _Product {
    public static final String ID = "id";
    public static final String IS_DISCOUNTED = "isDiscounted";
    public static final String NAME = "name";
    public static final String PRICE = "price";
    public static final String VERSION = "version";

    public static final SortableAttribute<Product> id = new SortableAttributeRecord(ID);
    public static final SortableAttribute<Product> isDiscounted = new SortableAttributeRecord(IS_DISCOUNTED);
    public static final TextAttribute<Product> name = new TextAttributeRecord(NAME);
    public static final SortableAttribute<Product> price = new SortableAttributeRecord(PRICE);
    public static final SortableAttribute<Product> version = new SortableAttributeRecord(VERSION);
}

The following example shows the repository and static metamodel being used,

@DataSourceDefinition(name = "java:app/jdbc/my-example-data",
                      className = "org.postgresql.xa.PGXADataSource",
                      databaseName = "ExampleDB",
                      serverName = "localhost",
                      portNumber = 5432,
                      user = "${example.database.user}",
                      password = "${example.database.password}")
public class MyServlet extends HttpServlet {
    @Inject
    Products products;

    protected void doGet(HttpServletRequest req, HttpServletResponse resp)
            throws ServletException, IOException {
        // Insert:
        Product prod = ...
        prod = products.add(prod);

        // Find the price of one product:
        price = products.getPrice(productId).orElseThrow();

        // Find all, sorted:
        List<Product> all = products.findByNameIgnoreCaseContains(searchFor, Order.by(
                                     _Product.price.desc(),
                                     _Product.name.asc(),
                                     _Product.id.asc()));

        // Find the first 20 most expensive products on sale:
        Page<Product> page1 = products.find(onSale, Order.by(_Product.price.desc(),
                                                             _Product.name.asc(),
                                                             _Product.id.asc())
                                                         .pageSize(20));
        ...
    }
}

To use this feature, add the following code to your server.xml file:

<featureManager>
     <feature>data-1.0</feature>
</featureManager>

Jakarta Expression Language 6.0

The expressionLanguage-6.0 feature is an implementation of the Expression Language 6.0 Specification for Jakarta EE 11. The Expression Language 6.0 specification includes a number of new features and specification clarifications.

Support for java.util.Optional (not enabled by default) and java.lang.Record is added. Another new feature is the addition of the length property for Arrays. For more information and the change history of the specification between Expression Language 5.0 and Expression Language 6.0, see Changes between 6.0 and 5.0.

To use this feature, add the following code to your server.xml file:

<featureManager>
     <feature>expressionLanguage-6.0</feature>
</featureManager>

For more information, see the Jakarta Expression Language 6.0 specification and Javadocs.

Jakarta Pages 4.0

The pages-4.0 feature is an implementation of the Pages 4.0 Specification for Jakarta EE 11. The Pages 4.0 specification includes a couple of new features and the removal of previously deprecated functions.

The jakarta.servlet.jsp.ErrorData class was updated to add support for the new jakarta.servlet.error.method and jakarta.servlet.error.query_string attributes. The following deprecated classes, methods, and actions were removed:

jakarta.servlet.jsp.JspException.getRootCause()
Classes in jakarta.servlet.jsp.el.
isThreadSafe page directive
jsp:plugin action and related actions
jakarta.servet.jsp.tagext.BodyTag.EVAL_BODY_TAG constant
Any methods that implemented jakarta.el.ELResolver.getFeatureDescriptors() were removed as the getFeatureDescriptors() method was removed in Expression Language 6.0.

For more information and the change history of the specification between Pages 3.1 and Pages 4.0, see Changes between 3.1 and 4.0.

To use this feature, add the following code to your server.xml file:

<featureManager>
     <feature>pages-4.0</feature>
</featureManager>

For more information, see the Jakarta Pages 4.0 Specification.

Jakarta Servlet 6.1

The Open Liberty servlet-6.1 feature is an implementation of the Servlet 6.1 specification for Jakarta EE 11 . It includes a number of new features, specification clarifications, and deprecates some existing servlet features.

Before Servlet 6.1, there was no way for an application to control the response data when doing a send redirect, as well as the response status code, which was always set to 302. An application could not easily retrieve the initial request’s query string or request HTTP method during an error handling dispatch. It also could not set the character encoding for a request or a response using the java.nio.charset.Charset; the only available option was using a String. During the read or write of servlet data, the jakarta.servlet.ServletInputStream or jakarta.servlet.ServletOutputStream only supports a byte array.

Servlet 6.1 provides servlet APIs that allow the send redirect to include an optional response data or set a compliant status code, instead of the default 302. Additional request attributes are available during the error handling process to easily retrieve the initial request’s query string or method. Furthermore, international applications can now set the character encoding using a Charset instead of a String. The ServletInputStream or ServletOutputStream can use java.nio.ByteBuffer to read or write the data.

Several clarifications are added to the behavior of the existing servlet APIs. For example, the getParameter family from the jakarta.servlet.ServletRequest is now throwing the runtime java.lang.IllegalStateException when an error occurs during the parsing of the request’s parameters. While processing an error-handling dispatch, the HTTP GET method is always used instead of the original request’s HTTP method.

To use this feature, add the following code to your server.xml file:

<featureManager>
   <feature>servlet-6.1</feature>
</featureManager>

For more information, see the Jakarta Servlet 6.1 specification.

Use InstantOn with IBM® MQ in Liberty

The 24.0.0.5-beta release introduces InstantOn feature support for Jakarta Messaging, Jakarta Connectors, and Jakarta Enterprise Beans Message-Driven Beans (MDB). InstantOn now provides blazing fast startup times for applications that use resource adapters to access external EIS resources, including applications that use the Jakarta Messaging API to access external messaging systems, like IBM® MQ. These "messaging client" applications can also manage message delivery to endpoints with message-driven bean listeners.

Here’s a server configuration snippet to deploy applications that use the JakartaEE-10 Messaging API and require the IBM® MQ resource adapter to access external messaging resources. This configuration automatically includes the connectors-2.1 feature, which supports the resource adapter configuration element.

<featureManager>
   <feature>messaging-3.1</feature>
   <feature>mdb-4.0</feature>
   <feature>servlet-6.0</feature>
<featureManager/>

<resourceAdapter id="mqJms" location="${server.config.dir}/wmq.jakarta.jmsra-9.3.5.0.rar"/>

You can use the MQ in Container image to stand up an MQ server that provides the following resources: queue manager QM1, queue DEV.QUEUE.1, channel DEV.APP.SVRCONN, and listener SYSTEM.LISTENER.TCP.1 on port 1414. These resources can support a simple point-to-point messaging scenario and are named within the messaging feature configuration elements shown in the following example.

InstantOn can dynamically update the messaging and connectors configuration elements to enable connections to external resources that are made available in any environment where a server is restored from checkpoint.

In the following example, the messaging configuration elements use Liberty variables named MQ_HOSTNAME and MQ_PORT to specify the hostname and IP port of the system that the MQ queue manager runs on. You can define these variables in the server.env file of a checkpointed server. When the server is restored, the queue connection factory and message endpoint activation configurations update to the environment-specific hostname and port values for the MQ queue manager.

   <jmsQueue id="jms/queue1" jndiName="jms/queue1">
      <properties.mqJms  baseQueueName="DEV.QUEUE.1"  baseQueueManagerName="QM1"/>
   </jmsQueue>

   <variable name="MQ_PORT" value="1414"/>
   <variable name="MQ_HOSTNAME" value="localhost"/>

   <jmsQueueConnectionFactory jndiName="jms/qcf1" connectionManagerRef="ConMgr7">
      <properties.mqJms  hostName="${MQ_HOSTNAME}"  port="${MQ_PORT}"
            channel="DEV.APP.SVRCONN"  queueManager="QM1"/>
   </jmsQueueConnectionFactory>

   <jmsConnectionFactory jndiName="jms/cf1" connectionManagerRef="ConMgr1">
      <properties.mqJms  hostName="${MQ_HOSTNAME}"  port="${MQ_PORT}"
            channel="DEV.APP.SVRCONN"  queueManager="QM1"/>
   </jmsConnectionFactory>
    <connectionManager id="ConMgr1" maxPoolSize="10"/>

   <jmsActivationSpec id="myapp/mymdb/FVTMessageDrivenBean">
      <properties.mqJms  destinationRef="jms/queue1"  destinationType="jakarta.jms.Queue"
            transportType="CLIENT"  hostName="${MQ_HOSTNAME}"  port="${MQ_PORT}"
            channel="DEV.APP.SVRCONN"  queueManager="QM1"/>
   </jmsActivationSpec>

Enjoy the time savings and stay tuned for upcoming announcements regarding InstantOn support for Jakarta features.

Try it now

If you’re using Maven, you can install the All Beta Features package using:

<plugin>
    <groupId>io.openliberty.tools</groupId>
    <artifactId>liberty-maven-plugin</artifactId>
    <version>3.10.2</version>
    <configuration>
        <runtimeArtifact>
          <groupId>io.openliberty.beta</groupId>
          <artifactId>openliberty-runtime</artifactId>
          <version>24.0.0.5-beta</version>
          <type>zip</type>
        </runtimeArtifact>
    </configuration>
</plugin>

<dependency>
    <groupId>org.example.spec</groupId>
    <artifactId>exampleApi</artifactId>
    <version>7.0</version>
    <type>pom</type>
    <scope>provided</scope>
</dependency>
<dependency>
    <groupId>example.platform</groupId>
    <artifactId>example.example-api</artifactId>
    <version>11.0.0</version>
    <scope>provided</scope>
</dependency>

Or for Gradle:

buildscript {
    repositories {
        mavenCentral()
    }
    dependencies {
        classpath 'io.openliberty.tools:liberty-gradle-plugin:3.8.2'
    }
}
apply plugin: 'liberty'
dependencies {
    libertyRuntime group: 'io.openliberty.beta', name: 'openliberty-runtime', version: '[24.0.0.5-beta,)'
}

Or if you’re using container images:

FROM icr.io/appcafe/open-liberty:beta

Or take a look at our Downloads page.

If you’re using IntelliJ IDEA, Visual Studio Code or Eclipse IDE, you can also take advantage of our open source Liberty developer tools to enable effective development, testing, debugging, and application management all from within your IDE.

For more information on using a beta release, refer to the Installing Open Liberty beta releases documentation.

We welcome your feedback

Let us know what you think on our mailing list. If you hit a problem, post a question on StackOverflow. If you hit a bug, raise an issue.

Java SE 22 support in 24.0.0.4

Tue, 23 Apr 2024 00:00:00 +0000

The 24.0.0.4 release introduces support for Java SE 22 and includes CVE fixes. We’ve also updated several Open Liberty guides to use MicroProfile Reactive Messaging 3.0, MicroProfile 6.1, and Jakarta EE 10.

In Open Liberty 24.0.0.4:

Support for Java 22 in Open Liberty
8 guides are updated to use MicroProfile Reactive Messaging 3.0
Security Vulnerability (CVE) Fixes

Check out previous Open Liberty GA release blog posts.

Develop and run your apps using 24.0.0.4

If you’re using Maven, include the following in your pom.xml file:

<plugin>
    <groupId>io.openliberty.tools</groupId>
    <artifactId>liberty-maven-plugin</artifactId>
    <version>3.10.2</version>
</plugin>

Or for Gradle, include the following in your build.gradle file:

buildscript {
    repositories {
        mavenCentral()
    }
    dependencies {
        classpath 'io.openliberty.tools:liberty-gradle-plugin:3.8.2'
    }
}
apply plugin: 'liberty'

Or if you’re using container images:

FROM icr.io/appcafe/open-liberty

Or take a look at our Downloads page.

Support for Java SE 22 in Open Liberty

Java 22 is the latest release of Java SE, released in March 2024. It contains new features and enhancements over previous versions of Java. However, Java 22 is not a long-term support (LTS) release and support for it will be dropped when the next version of Java is supported. It offers some new functions and changes that you are going to want to check out for yourself.

Check out the following feature changes in Java 22:

423: Region Pinning for G1
447: Statements before super(…) (Preview)
454: Foreign Function & Memory API
456: Unnamed Variables & Patterns
457: Class-File API (Preview)
458: Launch Multi-File Source-Code Programs
459: String Templates (Second Preview)
460: Vector API (Seventh Incubator)
461: Stream Gatherers (Preview)
462: Structured Concurrency (Second Preview)
463: Implicitly Declared Classes and Instance Main Methods (Second Preview)
464: Scoped Values (Second Preview)

Take advantage of the new changes in Java 22 in Open Liberty now and get more time to review your applications, microservices, and runtime environments on your favorite server runtime!

To use Java 22 with Open Liberty, just download the latest release of Java 22 and install the 24.0.0.4 version of Open Liberty. Then, edit your Liberty server.env file to point the JAVA_HOME environment variable to your Java 22 installation and start testing today.

For more information about Java 22, see the following resources:

8 guides are updated to use MicroProfile Reactive Messaging 3.0

The following 8 guides are updated to use the MicroProfile Reactive Messaging 3.0, MicroProfile 6.1 and Jakarta EE 10 specifications:

Also, the integration tests in these guides are updated to use Testcontainers. To learn how to test reactive Java microservices in true-to-production environments using Testcontainers, try out the Testing reactive Java microservices guide.

Security vulnerability (CVE) fixes in this release

CVE	CVSS score by X-Force®	Vulnerability assessment	Versions affected	Version fixed	Notes
CVE-2023-51775	7.5	Denial of service	21.0.0.3 - 24.0.0.3	24.0.0.4	Affects the openidConnectClient-1.0, socialLogin-1.0, mpJwt-1.2, mpJwt-2.0, mpJwt-2.1, jwt-1.0 features
CVE-2024-27270	4.7	Cross-site scripting	23.0.0.3 - 24.0.0.3	24.0.0.4	Affects the servlet-6.0 feature

For a list of past security vulnerability fixes, reference the Security vulnerability (CVE) list.

Get Open Liberty 24.0.0.4 now

Available through Maven, Gradle, Docker, and as a downloadable archive.

Support for Java 22 and an updated preview of Jakarta Data in 24.0.0.4-beta

Tue, 09 Apr 2024 00:00:00 +0000

The 24.0.0.4-beta release introduces support for Java SE 22 and updates for the Jakarta Data 1.0 preview, including improvements for type safety and a new @Find annotation to define repository find methods.

The Open Liberty 24.0.0.4-beta includes the following beta features (along with all GA features):

Run your Open Liberty apps with Java 22
Try out new functions for Jakarta Data 1.0 at milestone 3

Run your Open Liberty apps with Java 22

Java 22 is the latest release of Java, released in March 2024. It contains new features and enhancements over previous versions of Java. However, Java 22 is not a long-term support (LTS) release and support for it will be dropped when the next version of Java is supported. It offers some new functions and changes that you are going to want to check out for yourself.

Check out the following feature changes in Java 22:

423: Region Pinning for G1
447: Statements before super(…) (Preview)
454: Foreign Function & Memory API
456: Unnamed Variables & Patterns
457: Class-File API (Preview)
458: Launch Multi-File Source-Code Programs
459: String Templates (Second Preview)
460: Vector API (Seventh Incubator)
461: Stream Gatherers (Preview)
462: Structured Concurrency (Second Preview)
463: Implicitly Declared Classes and Instance Main Methods (Second Preview)
464: Scoped Values (Second Preview)

Take advantage of the new changes in Java 22 in Open Liberty now and get more time to review your applications, microservices, and runtime environments on your favorite server runtime!

To use Java 22 with Open Liberty, just download the latest release of Java 22 and install the 24.0.0.4-beta version of Open Liberty. Then, edit your Liberty server.env file to point the JAVA_HOME environment variable to your Java 22 installation and start testing today. The 24.0.0.4-beta release introduces beta support for Java 22. As we work toward full Java 22 support, please bear with any of our implementations of these functions that might not be ready yet.

For more information about Java 22, see the following resources:

Try out new functions for Jakarta Data 1.0 at milestone 3

Jakarta Data is a new Jakarta EE open source specification that standardizes the popular Data Repository pattern across various providers. Open Liberty 24.0.0.4-beta includes the Jakarta Data 1.0 Milestone 3 release, which introduces the static metamodel and the ability to annotatively compose Find methods.

Jakarta Data 1.0 milestone 3 introduces the concept of a static metamodel, which allows for more type-safe usage, and the ability to define repository find methods with the @Find annotation. To use these capabilities, you need an Entity and a Repository.

annotated with jakarta.persistence.Entity and related annotations from Jakarta Persistence.
a Java class without entity annotations, in which case the primary key is inferred from an entity property that is named id or ending with Id and an entity property that is named version designates an automatically incremented version column.

The following example shows a simple entity:

@Entity
public class Product {
    @Id
    public long id;

    public boolean isDiscounted;

    public String name;

    public float price;

    @Version
    public long version;
}

@Repository(dataStore = "java:app/jdbc/my-example-data")
public interface Products extends BasicRepository<Product, Long> {
    @Insert
    Product add(Product newProduct);

    // parameter based query that requires compilation with -parameters to preserve parameter names
    @Find
    Optional<Product> find(long id);

    // parameter based query that does not require -parameters because it explicitly specifies the name
    @Find
    Page<Product> find(@By("isDiscounted") boolean onSale,
                       PageRequest<Product> pageRequest);

    // query-by-method name pattern:
    List<Product> findByNameIgnoreCaseContains(String searchFor, Order<Product> orderBy);

    // query via JPQL:
    @Query("UPDATE Product o SET o.price = o.price - (?2 * o.price), o.isDiscounted = true WHERE o.id = ?1")
    boolean discount(long productId, float discountRate);
}

Observe that the repository interface includes type parameters in PageRequest<Product> and Order<Product>. These parameters help ensure that the page request and sort criteria are for a Product entity, rather than some other entity. To enable this function, you can optionally define a static metamodel class for the entity (or various IDEs might generate one for you after the 1.0 specification is released). The following example shows that you can use with the Product entity,

@StaticMetamodel(Product.class)
public class _Product {
    public static volatile SortableAttribute<Product> id;
    public static volatile SortableAttribute<Product> isDiscounted;
    public static volatile TextAttribute<Product> name;
    public static volatile SortableAttribute<Product> price;
    public static volatile SortableAttribute<Product> version;

    // The static metamodel can also have String constants for attribute names,
    // but those are omitted from this example
}

The following example shows the repository and static metamodel being used:

@DataSourceDefinition(name = "java:app/jdbc/my-example-data",
                      className = "org.postgresql.xa.PGXADataSource",
                      databaseName = "ExampleDB",
                      serverName = "localhost",
                      portNumber = 5432,
                      user = "${example.database.user}",
                      password = "${example.database.password}")
public class MyServlet extends HttpServlet {
    @Inject
    Products products;

    protected void doGet(HttpServletRequest req, HttpServletResponse resp)
            throws ServletException, IOException {
        // Insert:
        Product prod = ...
        prod = products.add(prod);

        // Find one entity:
        prod = products.find(productId).orElseThrow();

        // Find all, sorted:
        List<Product> all = products.findByNameIgnoreCaseContains(searchFor, Order.by(
                                     _Product.price.desc(),
                                     _Product.name.asc(),
                                     _Product.id.asc()));

        // Find the first 20 most expensive products on sale:
        Page<Product> page1 = products.find(onSale, Order.by(_Product.price.desc(),
                                                             _Product.name.asc(),
                                                             _Product.id.asc())
                                                         .pageSize(20));
        ...
    }
}

To enable the new beta feature in your app, add it to your server.xml file:

<server>
  <featureManager>
    <feature>data-1.0</feature>
    ...
  </featureManager>
  ...
<server>

Try it now

If you’re using Maven, you can install the All Beta Features package by using:

<plugin>
    <groupId>io.openliberty.tools</groupId>
    <artifactId>liberty-maven-plugin</artifactId>
    <version>3.10.2</version>
    <configuration>
        <runtimeArtifact>
          <groupId>io.openliberty.beta</groupId>
          <artifactId>openliberty-runtime</artifactId>
          <version>24.0.0.4-beta</version>
          <type>zip</type>
        </runtimeArtifact>
    </configuration>
</plugin>

<dependency>
    <groupId>org.example.spec</groupId>
    <artifactId>exampleApi</artifactId>
    <version>7.0</version>
    <type>pom</type>
    <scope>provided</scope>
</dependency>
<dependency>
    <groupId>example.platform</groupId>
    <artifactId>example.example-api</artifactId>
    <version>11.0.0</version>
    <scope>provided</scope>
</dependency>

Or for Gradle:

buildscript {
    repositories {
        mavenCentral()
    }
    dependencies {
        classpath 'io.openliberty.tools:liberty-gradle-plugin:3.8.2'
    }
}
apply plugin: 'liberty'
dependencies {
    libertyRuntime group: 'io.openliberty.beta', name: 'openliberty-runtime', version: '[24.0.0.4-beta,)'
}

Or if you’re using container images:

FROM icr.io/appcafe/open-liberty:beta

Or take a look at our Downloads page.

If you’re using IntelliJ IDEA, Visual Studio Code or Eclipse IDE, you can also take advantage of our open source Liberty developer tools to enable effective development, testing, debugging, and application management all from within your IDE.

For more information on using a beta release, refer to the Installing Open Liberty beta releases documentation.

We welcome your feedback

Let us know what you think on our mailing list. If you hit a problem, post a question on StackOverflow. If you hit a bug, please raise an issue.

Run AI-enabled Jakarta EE and MicroProfile applications on Open Liberty

Mon, 01 Apr 2024 00:00:00 +0000

Artificial Intelligence (AI) is an exciting and disruptive field that is already transforming businesses, and even entire industries, by enabling automation, improving decision-making and unlocking new insights from data. With the rise in large language models (LLMs) such as ChatGPT, there is a significant shift in the performance of AI and its potential to drive enterprise value. So, how will this impact on software development and the creation of cloud-native Java applications for enterprises?

In this post, we’ll explore what LLMs are and how to use them in Java applications. We’ll also get started using them in an example Jakarta EE/MicroProfile app.

Find out what LLMs are
Explore app frameworks that simplify the use of LLMs
Discover how to use LangChain in Java applications
Try out the jakartaee-microprofile-example application
Learn how this sample application works

What are LLMs?

A language model is a model of natural language based on probabilities. They are able to generate probabilities of a series of words together. Large language models (LLMs) are simply language models that are categorized by their large size. They are trained on immense amounts of data, possibly billions of parameters, by using self-supervised and semi-supervised learning techniques. This training enables them to generate natural language and other types of content to perform a wide range of tasks.

Check out the introductory video for more information on LLMs, including what they are, how they work, and their business applications.

You can find LLMs in the service offerings of almost all of the major cloud service providers. For example, IBM offers models through its watsonx services, Microsoft Azure offers LLMs like Llama 2 and OpenAI GPT-4, and Amazon Bedrock offers models from a range of AI companies.

How can we take advantage of LLMs in Java applications?

Integrating AI/LLM capabilities into an application can be challenging. The open source LangChain framework was developed in 2022 to help streamline the process of creating generative AI apps.

LangChain provides tools and abstractions to improve the customization, accuracy, and relevancy of the information the models generate. For example, developers can use LangChain components to build new prompt chains or customize existing templates. LangChain also includes components that allow LLMs to access new data sets without retraining and organizes the large quantities of data these models require so that they can be accessed with ease.

Although LangChain is primarily available in Python and JavaScript/TypeScript versions, options are available to use LangChain in Java applications through community projects like LangChain4j. LangChain4j APIs can help integrate LLMs into your Java application for different AI platforms, such as OpenAI and Hugging Face.

How to use LangChain4j in a Jakarta EE and MicroProfile application

Langchain4j has a useful open source langchain4j-examples GitHub repository where it stores example applications. However, we could not find any examples showcasing how you could experience these AI technologies in a Jakarta EE or MicroProfile based application. So, we decided to build one ourselves called jakartaee-microprofile-example, which can now be found in this langchain4j-examples GitHub repository. This demo application highlights how to use LangChain4j APIs in an application by using Jakarta EE and MicroProfile on Open Liberty.

Try out the jakartaee-microprofile-example application

To see how you can apply LangChain4j to your own Jakarta EE and MicroProfile applications, check out this example project for yourself.

Prerequisites

Before you clone the application to your machine, install JDK 17, and ensure that your JAVA_HOME environment variable is set. You can use the IBM Semeru Runtime as your chosen Java runtime. This runtime offers performance benefits from deep technology investment in projects such as Eclipse OpenJ9 and is available across a wide variety of hardware and software platforms. To find out more about IBM Semeru Runtime, see Open Liberty and Semeru Runtimes, cloud-native performance that matters.

The application uses Hugging Face. You need to get a Hugging Face API Key:

Sign up and log in to https://huggingface.co
Go to the Access Tokens page
Create an access token with read role

To access the repository remotely, install Git if you haven’t already. You can clone the langchain4j-examples GitHub repository to your local machine by running the following command:

git clone https://github.com/langchain4j/langchain4j-examples.git

Environment setup

To run the application, navigate to the jakartaee-microprofile-example directory:

cd langchain4j-examples/jakartaee-microprofile-example

Set the following environment variables:

export JAVA_HOME=<your Java 17 home path>
export HUGGING_FACE_API_KEY=<your Hugging Face read token>

Start the application

To start the application, use the provided Maven wrapper to run Open Liberty in dev mode:

./mvnw liberty:dev

After you see the following message, the application is ready:

************************************************************************
*    Liberty is running in dev mode.
*        Automatic generation of features: [ Off ]
*        h - see the help menu for available actions, type 'h' and press Enter.
*        q - stop the server and quit dev mode, press Ctrl-C or type 'q' and press Enter.
*
*    Liberty server port information:
*        Liberty server HTTP port: [ 9080 ]
*        Liberty server HTTPS port: [ 9443 ]
*        Liberty debug port: [ 7777 ]
************************************************************************

To ensure that the application started successfully, you can run the tests by pressing the enter/return key from the command-line session. If the tests pass, you can see output similar to the following example:

[INFO] -------------------------------------------------------
[INFO]  T E S T S
[INFO] -------------------------------------------------------
[INFO] Running it.dev.langchan4j.example.ChatServiceIT
[INFO] ...
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.439 s...
[INFO] ...
[INFO] Running it.dev.langchan4j.example.ModelResourceIT
[INFO] Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.733 s...
[INFO]
[INFO] Results:
[INFO]
[INFO] Tests run: 4, Failures: 0, Errors: 0, Skipped: 0

Access the application

After the application is running, you can access it through a browser of your choice at http://localhost:9080/ and start experimenting with it.

You can type in any text that you want to chat with the AI agent. Here are some suggested messages:

What is MicroProfile?
Which top 10 companies contribute MicroProfile?
Any documentation?

How does the application work?

The application demonstrates how to use the LangChain4j APIs, Jakarta Contexts and Dependency Injection, Jakarta WebSocket, MicroProfile Config, and MicroProfile Metrics features.

Creating the LangChain4j AI service

The application uses the HuggingFaceChatModel class to provide the model for building the AI service.

See the src/main/java/dev/langchain4j/example/chat/ChatAgent.java file.

    public Assistant getAssistant() {
        ...
            HuggingFaceChatModel model = HuggingFaceChatModel.builder()
                .accessToken(HUGGING_FACE_API_KEY)
                .modelId(CHAT_MODEL_ID)
                .timeout(ofSeconds(TIMEOUT))
                .temperature(TEMPERATURE)
                .maxNewTokens(MAX_NEW_TOKEN)
                .waitForModel(true)
                .build();
            assistant = AiServices.builder(Assistant.class)
                .chatLanguageModel(model)
                .chatMemoryProvider(
                    sessionId -> MessageWindowChatMemory.withMaxMessages(MAX_MESSAGES))
                .build();
       ...
    }

Through the customized Assistant interface, the application can send messages to the LLM by its chat() method.

    interface Assistant {
       String chat(@MemoryId String sessionId, @UserMessage String userMessage);
    }

Externalizing the configuration

An API key is required to access the model. For security purposes, the key is not hardcoded in the code. The application externalizes the API key and the LangChain4j model properties with the MicroProfile Config feature that helps the application to run in different environments without code changes. You can learn more from the External configuration of microservices document.

See the src/main/java/dev/langchain4j/example/chat/ChatAgent.java file.

    @Inject
    @ConfigProperty(name = "hugging.face.api.key")
    private String HUGGING_FACE_API_KEY;

    @Inject
    @ConfigProperty(name = "chat.model.id")
    private String CHAT_MODEL_ID;

    @Inject
    @ConfigProperty(name = "chat.model.timeout")
    private Integer TIMEOUT;

    @Inject
    @ConfigProperty(name = "chat.model.max.token")
    private Integer MAX_NEW_TOKEN;

    @Inject
    @ConfigProperty(name = "chat.model.temperature")
    private Double TEMPERATURE;

    @Inject
    @ConfigProperty(name = "chat.memory.max.messages")
    private Integer MAX_MESSAGES;

To fine tune the LangChain4j model or even try out another LLM, you simply update the values in the langchain4j-examples/jakartaee-microprofile-example/src/main/resources/META-INF/microprofile-config.properties file or provide them through the environment variables.

hugging.face.api.key=set it by env variable
chat.model.id=NousResearch/Nous-Hermes-2-Mixtral-8x7B-DPO
chat.model.timeout=120
chat.model.max.token=200
chat.model.temperature=1.0
chat.memory.max.messages=20

Communicating between the client and LLM

The application provides the interactive UI client for users to communicate with the LLM. Jakarta WebSocket enables two-way communication between the client and the ChatService service. Each client makes an HTTP connection to the service and send out the messages by the send() method.

See the src/main/webapp/chatroom.js file.

    const webSocket = new WebSocket('ws://localhost:9080/chat');
    ...
    function sendMessage() {
        ...
        var myMessage = document.getElementById('myMessage').value;
        ...
        webSocket.send(myMessage);
        ...
    }

The service receives the user messages through the WebSocket onMessage() method, forwards them to the LLM by calling the ChatAgent.chat() method, and then broadcasts the LLM answers back to the client session through the sendObect() method.

See the src/main/java/dev/langchain4j/example/chat/ChatService.java file.

    @OnMessage
    public void onMessage(String message, Session session) {
        ...
        try {
            ...
            answer = agent.chat(sessionId, message);
        } catch (Exception e) {
            ...
        }

        try {
            session.getBasicRemote().sendObject(answer);
        } catch (Exception e) {
            e.printStackTrace();
        }

    }

Enabling metrics

To determine the performance and health of the application, it uses the MicroProfile Metrics feature to collect how much processing time is needed for a chat by applying the @Timed annotation to the onMessage() method.

See the src/main/java/dev/langchain4j/example/chat/ChatService.java file.

    @OnMessage
    @Timed(name = "chatProcessingTime",
           absolute = true,
           description = "Time needed chatting to the agent.")
    public void onMessage(String message, Session session) {
        ...

Visit the http://localhost:9080/metrics?scope=application URL to check out the metrics.

# HELP chatProcessingTime_seconds Time needed chatting to the agent.
# TYPE chatProcessingTime_seconds summary
chatProcessingTime_seconds{mp_scope="application",quantile="0.5",} 0.0
chatProcessingTime_seconds{mp_scope="application",quantile="0.75",} 0.0
chatProcessingTime_seconds{mp_scope="application",quantile="0.95",} 0.0
chatProcessingTime_seconds{mp_scope="application",quantile="0.98",} 0.0
chatProcessingTime_seconds{mp_scope="application",quantile="0.99",} 0.0
chatProcessingTime_seconds{mp_scope="application",quantile="0.999",} 0.0
chatProcessingTime_seconds_count{mp_scope="application",} 6.0
chatProcessingTime_seconds_sum{mp_scope="application",} 31.674357666
# HELP chatProcessingTime_seconds_max Time needed chatting to the agent.
# TYPE chatProcessingTime_seconds_max gauge
chatProcessingTime_seconds_max{mp_scope="application",} 13.191547042

If you are interested in other ways to use the LangChain4j APIs, you can study the REST APIs that are provided by the src/main/java/dev/langchain4j/example/rest/ModelResource.java file.

Where to next?

Check out the Open Liberty guides for more information and interactive tutorials that walk you through using more Jakarta EE and MicroProfile APIs with Open Liberty.

Helpful links

Our guide to open source cloud native Java at DevNexus 2024

Wed, 06 Mar 2024 00:00:00 +0000

What is DevNexus?

DevNexus is the longest-running and largest Java Conference in the US. It’s organised by a vibrant Java community who are passionate about enabling education for all and empowering the Java developer community. Last year’s event brought more than 1400 developers together from all over the world, and more than 90 speakers shared their knowledge on exciting, trending topics like software architecture, core Java, Kubernetes, and security.

You can see more of the 2023 highlights in this promo video. For those of you who are keen eyed, you might even spot our very own Liberty Space Rover!

This year the event is being held in downtown Atlanta at the Georgia World Congress Center from April 9th-11th and tickets are already sold out! It’s sure to be an awesome event, with 145 international speakers taking the stage.

Open Liberty Booth at DevNexus

This year we are excited to have our very own Open Liberty booth as well as having members of the Open Liberty team on site hosting sessions, quick labs, workshops, and running demonstrations at the IBM, MicroProfile and Jakarta EE booths.

We’re honoured to have a booth alongside other open source projects like MicroProfile, Jakarta EE, and PostgresSQL. Having our own booth gives attendees the opportunity to come and meet the people behind the technology and offers the chance to ask questions and learn more about these amazing open source projects!

So, if you’re coming to DevNexus, be sure to pop by our Open Liberty booth in the breaks and say hi. You may even get some cool Open Liberty swag!

Which session should I attend?

The great part about attending a conference like DevNexus is the huge array of topics, sessions, and speakers presenting throughout the event. You have the chance to learn about everything from agile, architecture, and AI, through to cloud infrastructure, cloud technologies, and core Java/Jakarta EE. But with over 140 different sessions to choose from, and up to 13 sessions all occurring at the same time, how do you choose which sessions to attend?!

Deciding which sessions to see can be a real challenge! But to help make this easier, we’ve put together this guide of the sessions available on each day that focus on open source, cloud-native Java technologies, including Open Liberty, MicroProfile, Jakarta EE, and more. There’s also a dedicated Jakarta EE track this year, so make sure to check out those sessions.

Tuesday 9th April 2024

Workshop: The Ultimate One-Day Java Workshop: Deploying AI-Enhanced Applications with Security & Scalability

This all-day workshop, led by 5 internationally renowned speakers, is sure to be a great hands-on learning experience. It bridges the gap between traditional Java application deployment and modern cloud-based solutions, offering participants a deep dive into the latest technologies, methodologies, and best practices, including the exciting realm of AI.

Wednesday 10th April 2024

Time: 10:00-11:00

Talk: Jakarta EE 11 - Performance and Developer Productivity

Jakarta EE guru Ivar Grimstad takes us on a journey to understand how the namespace change from javax. to jakarta. in Jakarta EE 9 impacted the entire Java ecosystem, the cool new features introduced in Jakarta EE 10, and the renewed focus on performance and developer productivity introduced in Jakarta EE 11.

Time: 11:30-12:30

Talk: Securing Your Enterprise Apps - Jakarta Security In Jakarta EE 11 And Beyond

Luis Neto showcases how Jakarta EE can help our applications constantly evolve to stay safe and remain secure, by defining a standard for creating secure enterprise Java applications, and innovating with each release to provide the best measures possible.

Time: 16:00-17:00

Talk: Optimize your applications to the max with Jakarta EE and MicroProfile

Join Java Champion Edwin Derks as he explores Jakarta EE, MicroProfile and application server runtimes and how they can provide the perfect tools to achieve optimal value when developing and running enterprise software.

Time: 17:00-18:00

Talk: Jakarta EE! The future of enterprise application behind the myths.

Concerned about moving your applications from JEE 5 & 7 to Jakarta EE 10? Join this session by Alberto Salazar to understand the potential pitfalls and put away the concerns of updating and evolving your enterprise applications.

Time: 17:00-18:00

Talk: The Next Frontier in Open Source Java Compilers: Just-In-Time Compilation as a Service

In this session, Rich Hagarty will dig into JITServer technology, showing the challenges of implementation, detailing its strengths and weaknesses, and illustrating its performance characteristics. For those interested in cloud native deployment, he will also show how to deploy it in containers, demonstrate its advantages compared to a traditional JIT compilation technique, and offer practical recommendations about when to use this technology.

Thursday 12th April 2024

Time: 10:00-11:00

Talk: Making the best of Jakarta EE, Kubernetes, WebSphere and the cloud with AI

This hands-on session will show you how to enable deployments of Jakarta EE applications using Open Liberty or WebSphere Liberty to the cloud with AI. With two Java champions presenting (Emily Jiang and Brian Benz), it’s sure to be a great session!

Time: 11:30-12:30

Talk: Exploring the Data Universe: Portability with Jakarta Data and Open Liberty

In this session, Jakarta Data committer Kyle Aure, will showcase the domain-driven repository pattern of the Jakarta Data project and highlight the query mechanism to utilize sorting, streaming, and paging. Using a live demo application, Kyle will swap out a relational database for a non-relational database to showcase just how easy this can now be with Jakarta Data!

Time: 11:30-12:30

Talk: Cache Me If You Can: Speed Up Your JVM With Project Valhalla

OpenJDK’s Project Valhalla is set to revolutionize how the JVM handles data objects in memory. This talk offers an exploration of Valhalla’s objectives, progress, and its potential impact on the Java ecosystem with examples throughout. Join Theresa Mammarella in this session to discover how Project Valhalla is on the verge of reshaping the landscape of Java, paving the way for a more efficient and high-performing future.

Time: 13:30-14:30

Talk: Databaseless Data Processing with EclipseStore and WebSphere Liberty InstantOn

Join Markus Kett and Java Champion Emily Jiang in this session to learn how the combinaton of Liberty InstantOn and EclipseStore enables Java applications to achieve the 3 most critical factors for cloud-native applicatons making use of AI, ML, VR, and big data in the cloud: high performance, low data storage costs, and simple, fast and cost-efficient implementation and maintenance.

Time: 13:30-14:30

Talk: Thriving in the cloud: Going beyond the 12 factors

Enabling applications to really thrive (and not just survive) in cloud environments can be challenging. The original 12 factor app methodology helped to lay out some of the key characteristics needed for cloud-native applications… but… as our cloud infrastructure and tooling has progressed, so too have these factors. In this session, Java Champion Grace Jansen will dive into the extended and updated 15 factors and take a look at open source technologies and tools that can help us achieve this.

Time: 16:00-17:00

Talk: Jakarta EE 11: Going Beyond the Era of Java EE

Java guru Michael Redlich presents this session providing a history of JavaEE/Jakarta EE and a review of new and updated specifications with code examples.

IBM Booth:

As well as the numerous sessions during the conference and our dedicated Open Liberty booth, the Open Liberty team will also be manning the IBM booth in the exhibition hall. Stop by to catch our in-booth theatre with a series of SmartTalks, grab some awesome swag, and have a chat about all things OSS Java. We’d love to see you there!

This year, we’ll also have our exciting intergalactic booth challenge… The Open Liberty Space Rover Challenge. In this challenge, you’ll need to navigate the planets and get your rover safely to your destination in the stars. Take control of a spaceship and use hand signals to direct it’s flight from planet to planet. Climb the rankings on your way to become top cadet in Star Academy. While you’re with us, ask our developers about the underlying technologies they’ve used to create the demo, including OpenJ9, Jakarta EE, MicroProfile, and "the most flexible runtime in the cosmos", Open Liberty.

Summary

We hope this guide helps you to plan your time at DevNexus. If you’re interested in other sessions, check out the full schedule on the DevNexus conference website.

Jakarta Data 1.0 hits Milestone 2 in 24.0.0.1-beta

Tue, 19 Dec 2023 00:00:00 +0000

Open Liberty 24.0.0.1-beta includes a preview of the new Jakarta Data specification for Jakarta EE, as it currently stands at Milestone 2. Milestone 2 provides API updates to pagination and various improvements to the Javadoc and specification text. You can try it out and give feedback on the specification so far.

Preview of Jakarta Data (Milestone 2)

Jakarta Data is a new Jakarta EE specification being developed in the open that standardizes the popular Data Repository pattern across a variety of providers. Open Liberty 24.0.0.1-beta includes the Jakarta Data 1.0 Milestone 2 release, which provides API updates to pagination and various improvements to the Javadoc and specification text. The Open Liberty beta includes a test implementation of Jakarta Data that we are using to experiment with proposed specification features so that developers can try out these features and provide feedback to influence the development of the Jakarta Data 1.0 specification beyond Milestone 2. The test implementation currently works with relational databases and operates by redirecting repository operations to the built-in Jakarta Persistence provider.

To use the pagination API to request pages of results in Jakarta Data, you need an Entity and a Repository.

annotated with jakarta.persistence.Entity and related annotations from Jakarta Persistence
a Java class without entity annotations, in which case the primary key is inferred from an entity property named id or ending with Id and an entity property named version designates an automatically incremented version column.

You define one or more repository interfaces for an entity, annotate those interfaces as @Repository and inject them into components via @Inject. The Jakarta Data provider supplies the implementation of the repository interface for you.

The following example shows a simple entity:

@Entity
public class Product {
    @Id
    public long id;

    public String name;

    public float price;

    @Version
    public long version;
}

The following example shows a repository that defines operations that relate to the entity. Your repository interface can inherit from built-in interfaces, such as BasicRepository and CrudRepository, to gain a variety of general purpose repository methods for inserting, updating, deleting, and querying for entities. However, in this case, we will define all of the methods ourselves by using the new lifecycle annotations:

@Repository(dataStore = "java:app/jdbc/my-example-data")
public interface Products {
    @Insert
    Product add(Product newProduct);

    @Update
    boolean modify(Product product);

    @Delete
    boolean remove(Product product);

    // parameter based query that requires compilation with -parameters to preserve parameter names
    Optional<Product> find(long id);

    // query-by-method name pattern:
    KeysetAwarePage<Product> findByNameIgnoreCaseContains(String searchFor, Pageable pageRequest);

    // query via JPQL:
    @Query("UPDATE Product o SET o.price = o.price - (?2 * o.price) WHERE o.id = ?1")
    boolean discount(long productId, float discountRate);
}

The following example shows the repository being used:

@DataSourceDefinition(name = "java:app/jdbc/my-example-data",
                      className = "org.postgresql.xa.PGXADataSource",
                      databaseName = "ExampleDB",
                      serverName = "localhost",
                      portNumber = 5432,
                      user = "${example.database.user}",
                      password = "${example.database.password}")
public class MyServlet extends HttpServlet {
    @Inject
    Products products;

    protected void doGet(HttpServletRequest req, HttpServletResponse resp)
            throws ServletException, IOException {
        // Insert:
        Product prod = ...
        prod = products.add(prod);

        // Update:
        prod.price = prod.price + 1.00;
        if (products.update(prod))
            System.out.println("Successfully increased the price.");
        else {
            // someone else either removed the product or updated its version before we could
            prod = products.find(productId).orElseThrow();
            ...
        }

        // Request only the first 10 results on a page, ordered by price, then name, then id:
        Pageable pageRequest = Pageable.size(10).sortBy(Sort.desc("price"), Sort.asc("name"), Sort.asc("id"));
        KeysetAwarePage<Product> page = products.findByNameIgnoreCaseContains(searchFor, pageRequest);
        ...
        // Request the next page relative to the end of the current page
        page = products.findByNameIgnoreCaseContains(searchFor, page.nextPageable());
        ...
        // Request the prior page relative to the start of the current page
        page = products.findByNameIgnoreCaseContains(searchFor, page.previousPageable());
        ...
    }
}

Try it now

If you’re using Maven, you can install the All Beta Features package using:

<plugin>
    <groupId>io.openliberty.tools</groupId>
    <artifactId>liberty-maven-plugin</artifactId>
    <version>3.10</version>
    <configuration>
        <runtimeArtifact>
          <groupId>io.openliberty.beta</groupId>
          <artifactId>openliberty-runtime</artifactId>
          <version>24.0.0.1-beta</version>
          <type>zip</type>
        </runtimeArtifact>
    </configuration>
</plugin>

You must also add dependencies to your pom.xml file for the beta version of the APIs that are associated with the beta features that you want to try. For example, for Jakarta EE 10 and MicroProfile 6, you would include:

<dependency>
    <groupId>org.eclipse.microprofile</groupId>
    <artifactId>microprofile</artifactId>
    <version>6.0-RC3</version>
    <type>pom</type>
    <scope>provided</scope>
</dependency>
<dependency>
    <groupId>jakarta.platform</groupId>
    <artifactId>jakarta.jakartaee-api</artifactId>
    <version>10.0.0</version>
    <scope>provided</scope>
</dependency>

Or for Gradle:

buildscript {
    repositories {
        mavenCentral()
    }
    dependencies {
        classpath 'io.openliberty.tools:liberty-gradle-plugin:3.8'
    }
}
apply plugin: 'liberty'
dependencies {
    libertyRuntime group: 'io.openliberty.beta', name: 'openliberty-runtime', version: '[24.0.0.1-beta,)'
}

Or if you’re using container images:

FROM icr.io/appcafe/open-liberty:beta

Or take a look at our Downloads page.

For more information on using a beta release, refer to the Installing Open Liberty beta releases documentation.

We welcome your feedback

Let us know what you think on our mailing list. If you hit a problem, post a question on StackOverflow. If you hit a bug, please raise an issue.

Preview of Jakarta Data Milestone 1 in Open Liberty 23.0.0.12-beta

Tue, 28 Nov 2023 00:00:00 +0000

Open Liberty 23.0.0.12-beta contains a preview of the new Jakarta Data specification for Jakarta EE, as it currently stands at Milestone 1. Milestone 1 provides the capability to annotate lifecycle methods such as Insert, Delete, and more. You can try it out and give feedback on the specification so far.

Also in this beta, you can configure the quiesce stage when the Liberty runtime shuts down to be longer than the default 30 seconds. This update is useful for services that need more time to finish processing requests.

The Open Liberty 23.0.0.12-beta includes the following beta features (along with all GA features):

Preview of Jakarta Data (Milestone 1)
Configurable Quiesce Timeout

Preview of Jakarta Data (Milestone 1)

Jakarta Data is a new Jakarta EE specification being developed in the open that aims to standardize the popular data repository pattern across a variety of providers. Open Liberty includes the Jakarta Data 1.0 Milestone 1 release, which adds the ability to annotatively compose custom lifecycle methods, covering Insert, Update, Save, and Delete operations. The Open Liberty beta includes a test implementation of Jakarta Data that we are using to experiment with proposed specification features so that developers can try out these features and provide feedback to influence the Jakarta Data 1.0 specification as it continues to be developed after Milestone 1. The test implementation currently works with relational databases and operates by redirecting repository operations to the built-in Jakarta Persistence provider.

Jakarta Data 1.0 Milestone 1 introduces the concept of annotated lifecycle methods. To use these methods, you need an entity and a repository.

annotated with jakarta.persistence.Entity and related annotations from Jakarta Persistence
a Java class without entity annotations, in which case the primary key is inferred from an entity property named id or ending with Id and an entity property named version designates an automatically incremented version column.

The following example shows a simple entity:

@Entity
public class Product {
    @Id
    public long id;

    public String name;

    public float price;

    @Version
    public long version;
}

@Repository(dataStore = "java:app/jdbc/my-example-data")
public interface Products {
    @Insert
    Product add(Product newProduct);

    @Update
    boolean modify(Product product);

    @Delete
    boolean remove(Product product);

    // parameter based query that requires compilation with -parameters to preserve parameter names
    Optional<Product> find(long id);

    // query-by-method name pattern:
    Page<Product> findByNameIgnoreCaseContains(String searchFor, Pageable pageRequest);

    // query via JPQL:
    @Query("UPDATE Product o SET o.price = o.price - (?2 * o.price) WHERE o.id = ?1")
    boolean discount(long productId, float discountRate);
}

The following example shows the repository being used:

@DataSourceDefinition(name = "java:app/jdbc/my-example-data",
                      className = "org.postgresql.xa.PGXADataSource",
                      databaseName = "ExampleDB",
                      serverName = "localhost",
                      portNumber = 5432,
                      user = "${example.database.user}",
                      password = "${example.database.password}")
public class MyServlet extends HttpServlet {
    @Inject
    Products products;

    protected void doGet(HttpServletRequest req, HttpServletResponse resp)
            throws ServletException, IOException {
        // Insert:
        Product prod = ...
        prod = products.add(prod);

        // Update:
        prod.price = prod.price + 1.00;
        if (products.update(prod))
            System.out.println("Successfully increased the price.");
        else {
            // someone else either removed the product or updated its version before we could
            prod = products.find(productId).orElseThrow();
            ...
        }

        // Request only the first 20 results on a page, ordered by price, then name, then id:
        Pageable pageRequest = Pageable.size(20).sortBy(Sort.desc("price"), Sort.asc("name"), Sort.asc("id"));
        Page<Product> page1 = products.findByNameIgnoreCaseContains(searchFor, pageRequest);
        ...
    }
}

Configurable quiesce timeout for the Liberty runtime

Liberty has a quiesce stage when shutting down the Liberty runtime, which prevents services from accepting new requests and allows time for services to process existing requests. The quiesce stage has always been a fixed 30 seconds time period. This quiesce time period is now configurable.

Previously, in some cases, the 30-seconds quiesce period was not long enough time for services to finish processing existing requests. So you can now increase the quiesce timeout if necessary.

To configure the quiesce timeout, add the new quiesceTimeout attribute to the executor element in the server.xml file:

<executor quiesceTimeout=“1m30s”/>

The timeout value is a positive integer followed by a unit of time, which can be hours (h), minutes (m), or seconds (s). For example, specify 30 seconds as 30s. You can include multiple units in a single entry. For example, 1m30s is equivalent to 90 seconds. The minimum quiesceTimeout value is 30 seconds. If you specify a shorter length of time, the value 30s is used.

Try it now

If you’re using Maven, you can install the All Beta Features package using:

<plugin>
    <groupId>io.openliberty.tools</groupId>
    <artifactId>liberty-maven-plugin</artifactId>
    <version>3.9</version>
    <configuration>
        <runtimeArtifact>
          <groupId>io.openliberty.beta</groupId>
          <artifactId>openliberty-runtime</artifactId>
          <version>23.0.0.12-beta</version>
          <type>zip</type>
        </runtimeArtifact>
    </configuration>
</plugin>

You must also add dependencies to your pom.xml file for the beta version of the APIs that are associated with the beta features that you want to try. For example, for Jakarta EE 10 and MicroProfile 6, you would include:

<dependency>
    <groupId>org.eclipse.microprofile</groupId>
    <artifactId>microprofile</artifactId>
    <version>6.0-RC3</version>
    <type>pom</type>
    <scope>provided</scope>
</dependency>
<dependency>
    <groupId>jakarta.platform</groupId>
    <artifactId>jakarta.jakartaee-api</artifactId>
    <version>10.0.0</version>
    <scope>provided</scope>
</dependency>

Or for Gradle:

buildscript {
    repositories {
        mavenCentral()
    }
    dependencies {
        classpath 'io.openliberty.tools:liberty-gradle-plugin:3.7'
    }
}
apply plugin: 'liberty'
dependencies {
    libertyRuntime group: 'io.openliberty.beta', name: 'openliberty-runtime', version: '[23.0.0.12-beta,)'
}

Or if you’re using container images:

FROM icr.io/appcafe/open-liberty:beta

Or take a look at our Downloads page.

For more information on using a beta release, refer to the Installing Open Liberty beta releases documentation.

We welcome your feedback

Let us know what you think on our mailing list. If you hit a problem, post a question on StackOverflow. If you hit a bug, please raise an issue.

MicroProfile 6.1, Java 21, and fast startup times for Spring Boot apps on Open Liberty 23.0.0.10-beta

Tue, 26 Sep 2023 00:00:00 +0000

This Open Liberty beta is packed full of the team’s latest standards implementation work with previews of MicroProfile 6.1 (Metrics, Telemetry, and OpenAPI), Java 21, and Jakarta Data (Beta 3) on Open Liberty. It also introduces faster startup times for your Spring Boot applications with little or no extra effort by using Liberty InstantOn; if you have any Spring apps to hand, give it a try. And there are a couple of updates that make it easier to manage security configurations in containerized environments.

The Open Liberty 23.0.0.10-beta includes the following beta features (along with all GA features):

Faster startup of Spring Boot apps (Spring Boot 3.0 InstantOn with CRaC)
Java 21 support
MicroProfile 6.1 support
- MicroProfile Metrics 5.1: configure statistics tracked by Histogram and Timer metrics
- MicroProfile Telemetry 1.1: updated OpenTelemetry implementation
MicroProfile OpenAPI 3.1: OpenAPI doc endpoint path configuration
Jakarta Data beta 3: configure the data source used to query and persist data
Support LTPA keys rotation without a planned outage
Include all files in a specified directory in your server configuration

Faster startup of Spring Boot apps (Spring Boot 3.0 InstantOn with CRaC)

The Spring Framework (version 6.1) is adding support for Coordinated Restore at Checkpoint (CRaC), which also uses CRIU to provide Checkpoint and Restore for Java applications. The Spring Boot version 3.2 will use Spring Framework version 6.1, enabling Spring Boot applications to also use CRaC to achieve rapid startup times.

The recent addition of the Open Liberty springBoot-3.0 feature allows Spring Boot 3.x-based applications to be deployed with Open Liberty. And now, with the new Open Liberty crac-1.3 beta feature, a Spring Boot 3.2-based application can be deployed with Liberty InstantOn to achieve rapid startup times for your Spring Boot application.

To use the CRaC 1.3 functionality with the springBoot-3.0 feature, you must be running with Java 17 or higher and use the crac-1.3 feature. Additionally, if your application uses Servlet, it needs to use the servlet-6.0 feature. These features are configured in the server.xml file as follows:

<features>
   <feature>springBoot-3.0</feature>
   <feature>servlet-6.0</feature>
   <feature>crac-1.3</feature>
</features>

With these features enabled you can containerize your Spring Boot 3.2 application with Liberty InstantOn support by following the Liberty InstantOn documentation along with following the Liberty recommendations for containerizing Spring Boot applications with the Liberty Spring Boot guide.

For more information and an example Spring Boot application using the Liberty InstantOn crac-1.3 feature, see the How to containerize your Spring Boot application for rapid startup blog post.

You can also use the crac-1.3 feature with other applications, such as applications using Jakarta EE or MicroProfile. Such applications can register resources with CRaC to get notifications for checkpoint and restore. This allows applications to perform actions necessary to prepare for a checkpoint as well as perform necessary actions when the application is restored. For more information on the org.crac APIs, see the org.crac Javadoc.

Java 21 support

Java 21 is finally here, the first long term support (LTS) release since Java 17 was released two years ago. It offers some new functionality and changes that you’ll want to check out for yourself.

As it is a milestone release of Java, we thought you might like to try it out a little early (we have been testing against Java 21 build 35 ourselves). Take advantage of trying out the new changes in Java 21 now and get more time to review your applications, microservices, and runtime environments.

Just:

Download the latest release of Java 21.
Get the 23.0.0.10-beta version of Open Liberty.
Edit your Liberty server’s server.env file to point JAVA_HOME to your Java 21 installation.
Start testing!

Here are some highlights from new JEP changes in Java 18-21:

400: UTF-8 by Default
408: Simple Web Server
413: Code Snippets in Java API Documentation
416: Reimplement Core Reflection with Method Handles
418: Internet-Address Resolution SPI
421: Deprecate Finalization for Removal
422: Linux/RISC-V Port
431: Sequenced Collections
439: Generational ZGC
440: Record Patterns
441: Pattern Matching for switch
449: Deprecate the Windows 32-bit x86 Port for Removal
451: Prepare to Disallow the Dynamic Loading of Agents
452: Key Encapsulation Mechanism API

But perhaps the most anticipated one of all is the introduction of Virtual Threads in Java 21:

444: Virtual Threads

Will the impact of Virtual Threads live up to the anticipation? Find out for yourself by experimenting with them, or with any of the other new features in Java 21, by trying them out in your applications run on the best Java runtime, Open Liberty!

For more information on Java 21, see:

As we work toward full Java 21 support, please bear with any of our functionality that might not be 100% ready yet.

MicroProfile 6.1 support

MicroProfile 6.1 is a minor release and is backwards-compatible with MicroProfile 6.0. It brings in Jakarta EE 10 Core Profile APIs and the following MicroProfile component specifications:

The following three specifications have minor updates, while the other five specifications remain unchanged:

MicroProfile Metrics 5.1
MicroProfile Telemetry 1.1
MicroProfile Config 3.1 (mainly some TCK updates to ensure the tests run against either CDI 3.x or CDI 4.0 Lite)

See the following sections for more details about each of these features and how to try them out.

MicroProfile Metrics 5.1: configure statistics tracked by Histogram and Timer metrics

MicroProfile Metrics 5.1 includes new MicroProfile Config properties that are used for configuring the statistics that the Histogram and Timer metrics track and output. In MicroProfile Metrics 5.0, the Histogram and Timer metrics only track and output the max recorded value, the sum of all values, the count of the recorded values, and a static set of percentiles for the 50th, 75th, 95th, 98th, 99th, and 99.9th percentile. These values are emitted to the /metrics endpoint in Prometheus format.

The new properties introduced in MicroProfile Metrics 5.1 allow you to define a custom set of percentiles as well as a custom set of histogram buckets for the Histogram and Timer metrics. There are also additional configuration properties for enabling a default set of histogram buckets, including properties for defining an upper and lower bound for the bucket set.

The properties in the following table allow you to define a semicolon-separated list of value definitions using the syntax:

metric_name=value_1[,value_2…value_n]

Property	Description
mp.metrics.distribution.percentiles	Defines a custom set of percentiles for matching Histogram and Timer metrics to track and output. Accepts a set of integer and decimal values for a metric name pairing. Can be used to disable percentile output if no value is provided with a metric name pairing.
mp.metrics.distribution.histogram.buckets	Defines a custom set of (cumulative) histogram buckets for matching Histogram metrics to track and output. Accepts a set of integer and decimal values for a metric name pairing.
mp.metrics.distribution.timer.buckets	Defines a custom set of (cumulative) histogram buckets for matching Timer metrics to track and output. Accepts a set of decimal values with a time unit appended (i.e., ms, s, m, h) for a metric name pairing.
mp.metrics.distribution.percentiles-histogram.enabled	Configures any matching Histogram or Timer metric to provide a large set of default histogram buckets to allow for percentile configuration with a monitoring tool. Accepts a true/false value for a metric name pairing.
mp.metrics.distribution.histogram.max-value	When percentile-histogram is enabled for a Timer, this property defines a upper bound for the buckets reported. Accepts a single integer or decimal value for a metric name pairing.
mp.metrics.distribution.histogram.min-value	When percentile-histogram is enabled for a Timer, this property defines a lower bound for the buckets reported. Accepts a single integer or decimal value for a metric name pairing.
mp.metrics.distribution.timer.max-value	When percentile-histogram is enabled for a Histogram, this property defines a upper bound for the buckets reported. Accepts a single decimal values with a time unit appended (i.e., ms, s, m, h) for a metric name pairing.
mp.metrics.distribution.timer.min-value	When percentile-histogram is enabled for a Histogram, this property defines a lower bound for the buckets reported. Accepts a single decimal value with a time unit appended (i.e., ms, s, m, h) for a metric name pairing.

Property

Description

mp.metrics.distribution.percentiles

Defines a custom set of percentiles for matching Histogram and Timer metrics to track and output.
Accepts a set of integer and decimal values for a metric name pairing.
Can be used to disable percentile output if no value is provided with a metric name pairing.

mp.metrics.distribution.histogram.buckets

Defines a custom set of (cumulative) histogram buckets for matching Histogram metrics to track and output.
Accepts a set of integer and decimal values for a metric name pairing.

mp.metrics.distribution.timer.buckets

Defines a custom set of (cumulative) histogram buckets for matching Timer metrics to track and output.
Accepts a set of decimal values with a time unit appended (i.e., ms, s, m, h) for a metric name pairing.

mp.metrics.distribution.percentiles-histogram.enabled

Configures any matching Histogram or Timer metric to provide a large set of default histogram buckets to allow for percentile configuration with a monitoring tool.
Accepts a true/false value for a metric name pairing.

mp.metrics.distribution.histogram.max-value

When percentile-histogram is enabled for a Timer, this property defines a upper bound for the buckets reported.
Accepts a single integer or decimal value for a metric name pairing.

mp.metrics.distribution.histogram.min-value

When percentile-histogram is enabled for a Timer, this property defines a lower bound for the buckets reported.
Accepts a single integer or decimal value for a metric name pairing.

mp.metrics.distribution.timer.max-value

When percentile-histogram is enabled for a Histogram, this property defines a upper bound for the buckets reported.
Accepts a single decimal values with a time unit appended (i.e., ms, s, m, h) for a metric name pairing.

mp.metrics.distribution.timer.min-value

When percentile-histogram is enabled for a Histogram, this property defines a lower bound for the buckets reported.
Accepts a single decimal value with a time unit appended (i.e., ms, s, m, h) for a metric name pairing.

Some properties can accept multiple values for a given metric name while some can only accept a single value. You can use an asterisk (i.e., *) as a wild card at the end of the metric name. For example, the mp.metrics.distribution.percentiles can be defined as:

mp.metrics.distribution.percentiles=alpha.timer=0.5,0.7,0.75,0.8;alpha.histogram=0.8,0.85,0.9,0.99;delta.*=

This example creates the alpha.timer timer metric to track and output the 50th, 70th, 75th, and 80th percentile values. The alpha.histogram histogram metric outputs the 80th, 85th, 90th, and 99th percentiles values. Percentiles are disabled for any Histogram or Timer metric that matches with delta.* .

We’ll expand on the previous example and define histogram buckets for the alpha.timer timer metric using the mp.metrics.distribution.timer.buckets property:

mp.metrics.distribution.timer.buckets=alpha.timer=100ms,200ms,1s

This configuration tells the metrics runtime to track and output the count of durations that fall within 0-100ms, 0-200ms, and 0-1 seconds. These values are ranges because the histogram buckets work cumulatively .

The corresponding Prometheus output for the alpha.timer metric at the /metrics REST endpoint is:

# HELP alpha_timer_seconds_max
# TYPE alpha_timer_seconds_max gauge
alpha_timer_seconds_max{scope="application",} 5.633
# HELP alpha_timer_seconds
# TYPE alpha_timer_seconds histogram (1)
alpha_timer_seconds{scope="application",quantile="0.5",} 0.67108864
alpha_timer_seconds{scope="application",quantile="0.7",} 5.603590144
alpha_timer_seconds{scope="application",quantile="0.75",} 5.603590144
alpha_timer_seconds{scope="application",quantile="0.8",} 5.603590144
alpha_timer_seconds_bucket{scope="application",le="0.1",} 0.0 (2)
alpha_timer_seconds_bucket{scope="application",le="0.2",} 0.0 (2)
alpha_timer_seconds_bucket{scope="application",le="1.0",} 1.0 (2)
alpha_timer_seconds_bucket{scope="application",le="+Inf",} 2.0  (2) (3)
alpha_timer_seconds_count{scope="application",} 2.0
alpha_timer_seconds_sum{scope="application",} 6.333

1	The Prometheus metric type is `histogram`. Both the quantiles or percentiles and buckets are represented under this type.
2	The `le` tag represents less than and is for the defined buckets, which are converted to seconds.
3	Prometheus requires a `+Inf` bucket, which counts all hits.

For more information about MicroProfile Metrics, see:

MicroProfile Telemetry 1.1: updated OpenTelemetry implementation

MicroProfile Telemetry 1.1 provides developers with the latest Open Telemetry technology; the feature now consumes OpenTelemetry-1.29.0, updated from 1.19.0. Consequently, a lot of the dependencies are now stable.

To enable the MicroProfile Telemetry 1.1 feature, add the following configuration to your server.xml:

<features>
   <feature>mpTelemetry-1.1</feature>
</features>

Additionally, you must make third-party APIs visible for your application in the server.xml:

<webApplication location="demo-microprofile-telemetry-inventory.war" contextRoot="/">
    <!-- enable visibility to third party apis -->
    <classloader apiTypeVisibility="+third-party"/>
</webApplication>

For more information about MicroProfile Telemetry, see:

MicroProfile OpenAPI 3.1: OpenAPI doc endpoint path configuration

MicroProfile OpenAPI generates and serves OpenAPI documentation for JAX-RS applications that are deployed to the Open Liberty server. The OpenAPI documentation is served from /openapi and a user interface for browsing this documentation is served from /openapi/ui.

With MicroProfile OpenAPI 3.1, you can configure the paths for these endpoints by adding configuration to your server.xml. For example:

<mpOpenAPI docPath="/my/openapi/doc/path" uiPath="/docsUi" />

When you set this configuration on a local test server, you can then access the OpenAPI document at localhost:9080/my/openapi/doc/path and the UI at localhost:9080/docsUi.

This is particularly useful if you want to expose the OpenAPI documentation through a Kubernetes ingress which routes requests to different services based on the path. For example, with this ingress configuration:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: my-ingress
spec:
rules:
- http:
    paths:
    - path: /appA
        pathType: Prefix
        backend:
        service:
            name: appA
            port:
            number: 9080

You could use the following server.xml configuration to ensure that the OpenAPI UI is available at /appA/openapi/ui:

<mpOpenAPI docPath="/appA/openapi" />

When uiPath is not set, it defaults to the value of docPath with /ui appended.

For more information about MicroProfile OpenAPI, see:

Jakarta Data beta 3: configure the data source used to query and persist data

Jakarta Data is a new Jakarta EE specification being developed in the open that aims to standardize the popular data repository pattern across a variety of providers. Open Liberty includes the Jakarta Data 1.0 beta 3 release, which adds the ability to configure the data source that a Jakarta Data repository uses to query and persist data.

The Open Liberty beta includes a test implementation of Jakarta Data that we are using to experiment with proposed specification features so that developers can try out these features and provide feedback to influence the specification as it is being developed. The test implementation currently works with relational databases and operates by redirecting repository operations to the built-in Jakarta Persistence provider. In preparation for Jakarta EE 11, which will require a minimum of Java 21 (not yet generally available), it runs on Java 17 and simulates the entirety of the Jakarta Data beta 3 release, plus some additional proposed features that are under consideration.

Jakarta Data beta 3 allows the use of multiple data sources, with a specification-defined mechanism for choosing which data source a repository will use.

To use Jakarta Data, you start by defining an entity class that corresponds to your data. With relational databases, the entity class corresponds to a database table and the entity properties (public methods and fields of the entity class) generally correspond to the columns of the table. You can define an entity class in one of the following ways:

Annotate the class with jakarta.persistence.Entity and related annotations from Jakarta Persistence.
Define a Java class without entity annotations, in which case the primary key is inferred from an entity property named id or ending with Id.

You define one or more repository interfaces for an entity, annotate those interfaces as @Repository, and inject them into components using @Inject. The Jakarta Data provider supplies the implementation of the repository interface for you.

Here’s a simple entity:

public class Product { // entity
    public long id;
    public String name;
    public float price;
}

The following example shows a repository that defines operations relating to the entity. It opts to specify the JNDI name of a data source where the entity data is to be stored and found:

@Repository(dataStore = "java:app/jdbc/my-example-data")
public interface Products extends CrudRepository<Product, Long> {
    // query-by-method name pattern:
    Page<Product> findByNameIgnoreCaseContains(String searchFor, Pageable pageRequest);

    // query via JPQL:
    @Query("UPDATE Product o SET o.price = o.price - (?2 * o.price) WHERE o.id = ?1")
    boolean discount(long productId, float discountRate);
}

In the following example, we have chosen to define the data source with the @DataSourceDefinition annotation, which we can place on a web component, such as the following example servlet. We can then inject the repository and use it:

@DataSourceDefinition(name = "java:app/jdbc/my-example-data",
                      className = "org.postgresql.xa.PGXADataSource",
                      databaseName = "ExampleDB",
                      serverName = "localhost",
                      portNumber = 5432,
                      user = "${example.database.user}",
                      password = "${example.database.password}")
public class MyServlet extends HttpServlet {
    @Inject
    Products products;

    protected void doGet(HttpServletRequest req, HttpServletResponse resp)
            throws ServletException, IOException {
        // Request only the first 20 results on a page, ordered by price, then name, then id:
        Pageable pageRequest = Pageable.size(20).sortBy(Sort.desc("price"), Sort.asc("name"), Sort.asc("id"));
        Page<Product> page1 = products.findByNameIgnoreCaseContains(searchFor, pageRequest);
    }
}

The dataStore field of @Repository can also point at the id of a databaseStore element or the id or jndiName of a dataSource element from server configuration, or the name of a resource reference that is available to the application.

For more information about Jakarta Data, see:

Your feedback is welcome on all of the Jakarta Data features and will be helpful as the specification develops further. Let us know what you think and/or be involved directly in the specification on github.

Support LTPA keys rotation without a planned outage

Open Liberty can now automatically generate new primary LTPA keys files while continuing to use validation keys files to validate LTPA tokens. This update enables you to rotate LTPA keys without any disruption to the application’s user experience. Previously, application users had to log in to their applications again after the Liberty server LTPA keys were rotated, which is no longer necessary.

Primary Keys are LTPA keys in the specified keys default ltpa.keys file. Primary keys are used both for generating new LTPA tokens and for validating LTPA tokens. There can only be one primary keys file per Liberty runtime.

Validation keys are LTPA keys in any .keys files other than the primary keys file. The validation keys are used only for validating LTPA tokens. They are not used for generating new LTPA tokens. All validation keys must be located in the same directory as the primary keys file.

There are 2 ways to enable LTPA keys rotation without a planned outage: monitoring the primary keys file directory or specifying the validation keys file.

Monitor the directory of the primary keys file for any new validation keys files.

Enable the monitorDirectory and monitorInterval attributes. For example, add the following configurations to the server.xml:

<ltpa monitorDirectory="true" monitorInterval="5m"/>

The monitorDirectory attribute monitors the ${server.config.dir}/resources/security/ directory by default, but can monitor any directory the primary keys file is specified in. The directory monitor looks for any LTPA keys files with the .keys extension. The Open Liberty server reads these LTPA keys and uses them as validation keys.

If the monitorInterval is set to 0, the default value, the directory is not monitored.

The ltpa.keys file can be renamed, for example, validation1.keys and then Liberty automatically regenerates a new ltpa.keys file with new primary keys that are used for all new LTPA tokens created. The keys in validation1.keys continue to be used for validating existing LTPA tokens.

When the validation1.keys are no longer needed, remove them by deleting the file or by setting monitorDirectory to false. It is recommended to remove unused validation keys as it can improve performance.

Specify the validation keys file and optionally specify a date-time to stop using the validation keys.

Copy the primary keys file (ltpa.keys) to a validation keys file, for example validation1.keys.
Modify the server configuration to use the validation keys file by specifying a validationKeys server configuration element inside the ltpa element. For example, add the following configuration to the server.xml file:

<ltpa>
    <validationKeys fileName="validation1.keys" password="{xor}Lz4sLCgwLTs=" notUseAfterDate="2024-01-02T12:30:00Z"/>
<ltpa/>

The validation1.keys file can be removed from use at a specified date-time in the future with the optional notUseAfterDate attribute. It is recommended to use notUseAfterDate to ignore validation keys after a given period as it can improve performance.

The fileName and password attributes are required in the validationKeys element, but notUseAfterDate is optional.

After the validation keys file is loaded from the server configuration update, the original primary keys file (ltpa.keys) can be deleted, which triggers new primary keys to be created while continuing to use validation1.keys for validation.

Specifying validation keys in this way can be combined with enabling monitor directory to also use validation keys that are not specified in the server.xml configuration at the same time. For example:

<ltpa monitorDirectory="true" monitorInterval="5m">
    <validationKeys fileName="validation1.keys" password="{xor}Lz4sLCgwLTs=" notUseAfterDate="2024-01-02T12:30:00Z"/>
<ltpa/>

To see all of the Liberty <ltpa> server configuration options see LTPA configuration docs.

Include all files in a specified directory in your server configuration

You can use the include element in your server.xml file to specify the location of files to include in your server configuration. In previous releases, you had to specify the location for each include file individually. Now, you can place all the included files in a directory and just specify the directory location in the include element.

This is important because when running on Kubernetes, mounting secrets as a whole folder is the only way to reflect the change from the secret dynamically in the running pod.

In the location attribute of the include element of the server.xml file, enter the directory that contains your configuration files. For example:

    <include location="./common/"/>

After you make the changes, you can see the following output in the log:

[AUDIT   ] CWWKG0028A: Processing included configuration resource: /Users/rickyherget/libertyGit/open-liberty/dev/build.image/wlp/usr/servers/com.ibm.ws.config.include.directory/common/a.xml
[AUDIT   ] CWWKG0028A: Processing included configuration resource: /Users/rickyherget/libertyGit/open-liberty/dev/build.image/wlp/usr/servers/com.ibm.ws.config.include.directory/common/b.xml
[AUDIT   ] CWWKG0028A: Processing included configuration resource: /Users/rickyherget/libertyGit/open-liberty/dev/build.image/wlp/usr/servers/com.ibm.ws.config.include.directory/common/c.xml

The files in the directory are processed in alphabetical order and subdirectories are ignored.

For more information about Liberty configuration includes, see Include configuration docs.

Try it now

If you’re using Maven, you can install the All Beta Features package using:

<plugin>
    <groupId>io.openliberty.tools</groupId>
    <artifactId>liberty-maven-plugin</artifactId>
    <version>3.8.2</version>
    <configuration>
        <runtimeArtifact>
          <groupId>io.openliberty.beta</groupId>
          <artifactId>openliberty-runtime</artifactId>
          <version>23.0.0.10-beta</version>
          <type>zip</type>
        </runtimeArtifact>
    </configuration>
</plugin>

You must also add dependencies to your pom.xml file for the beta version of the APIs that are associated with the beta features that you want to try. For example, for Jakarta Data Beta 3, you would include:

<dependency>
    <groupId>jakarta.data</groupId>
    <artifactId>jakarta-data-api</artifactId>
    <version>1.0.0-b3</version>
</dependency>

For Gradle, you can install the All Beta Features package using:

buildscript {
    repositories {
        mavenCentral()
    }
    dependencies {
        classpath 'io.openliberty.tools:liberty-gradle-plugin:3.6.2'
    }
}
apply plugin: 'liberty'
dependencies {
    libertyRuntime group: 'io.openliberty.beta', name: 'openliberty-runtime', version: '[23.0.0.10-beta,)'
}

Or if you’re using container images:

FROM icr.io/appcafe/open-liberty:beta

Or take a look at our Downloads page.

If you’re using IntelliJ IDEA, Visual Studio Code, or Eclipse IDE, try our open source Liberty developer tools for efficient development, testing, debugging, and application management, all within your IDE.

For more information on using a beta release, refer to the Installing Open Liberty beta releases documentation.

We welcome your feedback

Let us know what you think on our mailing list. If you hit a problem, post a question on StackOverflow. If you hit a bug, please raise an issue.

Simplifying data access with MySQL and Jakarta Data

Fri, 22 Sep 2023 00:00:00 +0000

Many applications, especially in the enterprise domain, persist or access data in some form. Relational databases are still by far the most used persistence mechanism even though they are being challenged by technologies such as NoSQL databases. This article explores some concepts for data access and looks at how the new Jakarta Data specification makes data access simpler than ever for application developers.

Spring Boot 3 support and Jakarta Data preview in Open Liberty 23.0.0.9-beta

Tue, 05 Sep 2023 00:00:00 +0000

The Open Liberty 23.0.0.9-beta release continues progress on two features that were introduced in previous betas: Spring Boot 3 support and the Jakarta Data preview.

The Liberty Spring Boot Support 3.0 feature provides more complete support for running a Spring Boot 3.0 application on Liberty. It also provides the capability to "thin" the application when you create applications in containers. More information is available in the Spring Boot 3 support in Open Liberty 23.0.0.8-beta blog post.

Jakarta Data is a new Jakarta EE specification being developed that aims to standardize the popular Data Repository pattern across a variety of providers. More information is available in the Jakarta Data beta 2 update in Open Liberty 23.0.0.7-beta blog post.

The 23.0.0.9-beta release also includes all GA features.

Try it now

To try out these features, update your build tools to pull the Open Liberty All Beta Features package instead of the main release. The beta works with Java SE 20, Java SE 17, Java SE 11, and Java SE 8.

If you’re using Maven, you can install the All Beta Features package using:

<plugin>
    <groupId>io.openliberty.tools</groupId>
    <artifactId>liberty-maven-plugin</artifactId>
    <version>RELEASE</version>
    <configuration>
        <runtimeArtifact>
          <groupId>io.openliberty.beta</groupId>
          <artifactId>openliberty-runtime</artifactId>
          <version>23.0.0.9-beta</version>
          <type>zip</type>
        </runtimeArtifact>
    </configuration>
</plugin>

<dependency>
  <groupId>jakarta.data</groupId>
  <artifactId>jakarta-data-api</artifactId>
  <version>1.0.0-b2</version>
</dependency>

Or for Gradle:

dependencies {
    libertyRuntime group: 'io.openliberty.beta', name: 'openliberty-runtime', version: '[23.0.0.9-beta,)'
}

Or if you’re using container images:

FROM icr.io/appcafe/open-liberty:beta

Or take a look at our Downloads page.

For more information on using a beta release, refer to the Installing Open Liberty beta releases documentation.

We welcome your feedback

Let us know what you think on our mailing list. If you hit a problem, post a question on StackOverflow. If you hit a bug, please raise an issue.

Spring Boot 3 support in Open Liberty 23.0.0.8-beta

Thu, 03 Aug 2023 00:00:00 +0000

Open Liberty 23.0.0.8-beta introduces support for Spring Boot 3, so you can use Spring Boot 3.x function in your Liberty applications. This beta release also includes the very early preview of Jakarta Data.

The Open Liberty 23.0.0.8-beta includes the following beta features (along with all GA features):

Spring Boot 3.0 support
Early preview of Jakarta Data

Spring Boot 3.0 support

Prior releases of Liberty provided support for Spring Boot 1.5 and Spring Boot 2.0 applications. Liberty has also supported Spring Boot applications packaged as a WAR file, as demonstrated in this recent blog post. The Open Liberty 23.0.0.8-beta release enables you to deploy Spring Boot 3.x applications by enabling the springboot-3.0 feature, with support for both JAR and WAR file types.

To run a Spring Boot 3.x application on Liberty, you must be running with Java 17 or higher. Additionally, if your application uses the Jakarta Servlet feature, it must be Jakarta Servet 6.0. Configure these features in the server.xml file, as shown in the following example:

<features>
   <feature>springboot-3.0</feature>
   <feature>servlet-6.0</feature>
</features>

As with previous versions of the Spring Boot Support feature, Spring Boot application JAR files can be placed in the /dropins/spring/ directory. Alternatively, specify the Spring Boot configuration elements in the server.xml file. For example:

 <springBootApplication id="spring-boot-app" location="spring-boot-app-0.1.0.jar" name="spring-boot-app" />

If you have used previous versions of the Spring Boot Support feature and are now migrating your application to use Spring Boot 3, note the following requirements:

Jakarta EE 10 features must be used.
Security configuration requires in-application modifications.
- Spring Security without the WebSecurityConfigurerAdapter
- Authorize HttpServletRequests
A new server template (springBoot3) is available.

Early preview of Jakarta Data

The 23.0.0.8-beta release also includes a preview of Jakarta Data. More information is available in the Jakarta Data beta 2 update in Open Liberty 23.0.0.7-beta blog post.

Try it now

If you’re using Maven, add the All Beta Features package to your pom.xml file:

<plugin>
    <groupId>io.openliberty.tools</groupId>
    <artifactId>liberty-maven-plugin</artifactId>
    <version>RELEASE</version>
    <configuration>
        <runtimeArtifact>
          <groupId>io.openliberty.beta</groupId>
          <artifactId>openliberty-runtime</artifactId>
          <version>23.0.0.8-beta</version>
          <type>zip</type>
        </runtimeArtifact>
    </configuration>
</plugin>

<dependency>
  <groupId>jakarta.data</groupId>
  <artifactId>jakarta-data-api</artifactId>
  <version>1.0.0-b2</version>
</dependency>

Or for Gradle:

dependencies {
    libertyRuntime group: 'io.openliberty.beta', name: 'openliberty-runtime', version: '[23.0.0.8-beta,)'
}

Or if you’re using container images:

FROM icr.io/appcafe/open-liberty:beta

Or take a look at our Downloads page.

For more information on using a beta release, refer to the Installing Open Liberty beta releases documentation.

We welcome your feedback

Let us know what you think on our mailing list. If you hit a problem, post a question on StackOverflow. If you hit a bug, please raise an issue.

Liberty Tools, Maven plugin, and Gradle plugin updates for Java developers

Wed, 12 Jul 2023 00:00:00 +0000

Fast iterative development with Liberty Tools

Liberty Tools 23.0.6 are now available for Java developers to write cloud-native applications with Liberty.

Liberty Tools support popular integrated development environments (IDEs) such as Eclipse IDE, Visual Studio Code, and IntelliJ IDEA, allowing developers to focus on their code and rapidly iterate by using Liberty’s dev mode in their preferred IDE. Moreover, Liberty Tools provide editing assistance for developers to easily make changes to the Liberty configuration files, and coding assistance for writing applications that use Jakarta EE (9.x and later) and MicroProfile (3.x and later) APIs.

Learn more about Liberty Tools and download them from different IDE marketplaces:

Please share your feedback and what you would like to see in future releases by opening issues in the GitHub repositories for Liberty Tools for Eclipse IDE, Liberty Tools for Visual Studio Code, and Liberty Tools for IntelliJ IDEA.

Easily build, package, and run applications with Liberty Maven & Gradle plugins

Liberty build plugins enable developers to easily build and package their applications to run on Liberty using the popular Java build tools, Maven and Gradle. It’s always recommended to use the latest versions of these build plugins to ensure you have the most recent fixes and enhancements, Liberty Maven Plugin 3.8.2 and Liberty Gradle Plugin 3.6.2. For example, in Liberty Gradle Plugin 3.6, we added support for Gradle 8.x. For more information, see Liberty Maven Plugin release notes and Liberty Gradle Plugin release notes.

To use Liberty Maven Plugin 3.8.2, specify the following configuration in your Maven build file:

<plugin>
    <groupId>io.openliberty.tools</groupId>
    <artifactId>liberty-maven-plugin</artifactId>
    <version>3.8.2</version>
</plugin>

To use Liberty Gradle Plugin 3.6.2, specify the following configuration in your Gradle build file:

apply plugin: 'liberty'

buildscript {
    repositories {
        mavenCentral()
    }

    dependencies {
        classpath 'io.openliberty.tools:liberty-gradle-plugin:3.6.2'
    }
}

If you have requests or run into problems, create new issues in the GitHub repositories for Liberty Maven Plugin and Liberty Gradle Plugin.

Contribute to Open Liberty and leave your mark

Like the Open Liberty runtime itself, Liberty Tools, Liberty Maven Plugin, and Liberty Gradle Plugin are open source and are developed under the OpenLiberty organization on GitHub. You are welcome to contribute directly and make Liberty even better!

Take a look at the code, grab an issue, and send in a pull request:

Jakarta Data beta 2 update in Open Liberty 23.0.0.7-beta

Tue, 11 Jul 2023 00:00:00 +0000

Open Liberty 23.0.0.7-beta updates the Jakarta Data preview by including the entirety of the Jakarta Data beta 2 release, as well as some additional proposed features that are being considered.

The Open Liberty 23.0.0.7-beta includes the Jakarta Data feature, along with all GA features.

A Very Early Preview of Jakarta Data (23.0.0.7 beta)

In Open Liberty 23.0.0.2-beta, we introduced Jakarta Data, a new Jakarta EE specification being developed that aims to standardize the popular Data Repository pattern across a variety of providers. The 23.0.0.4-beta release updated the preview to the beta 2 version, which this beta release expands on to include functionality such as query-by-method name, sorting and pagination, interoperability with entity classes from Jakarta Persistence, interoperability with Jakarta Transactions, and more.

The Open Liberty beta includes a test implementation of Jakarta Data that we are using to experiment with proposed specification features so that developers can try out these features and provide feedback to influence the specification as it is being developed. The test implementation currently works with relational databases and operates by redirecting repository operations to the built-in Jakarta Persistence provider. In preparation for Jakarta EE 11, which will require a minimum of Java 21 (not yet available), the feature runs on Java 17 and simulates the entirety of the Jakarta Data beta 2 release, plus some additional proposed features that are being considered.

annotated with jakarta.persistence.Entity and related annotations from Jakarta Persistence
a Java class without entity annotations, in which case the primary key is inferred from an entity property named id or ending with Id.

You define one or more repository interfaces for an entity, annotate those interfaces as @Repository, and inject them into components with CDI. The Jakarta Data provider supplies the implementation of the repository interface for you.

The following example shows a simple entity with a single repository interface.

public class Product { // entity
    public long id;
    public String name;
    public float price;
}

@Repository
public interface Products extends CrudRepository<Product, Long> {
    // query-by-method name pattern:
    Page<Product> findByNameIgnoreCaseContains(String searchFor, Pageable pageRequest);

    // query via JPQL:
    @Query("UPDATE Product o SET o.price = o.price - (?2 * o.price) WHERE o.id = ?1")
    boolean discount(long productId, float discountRate);

    // experimental annotatively-defined query (not part of Jakarta Data 1.0)
    @Filter(by = "productId")
    @Update(attr = "price", op = Operation.Add)
    boolean increasePrice(long prodId, float amount);
}

public class MyServlet extends HttpServlet {
    @Inject
    Products products;

    protected void doGet(HttpServletRequest req, HttpServletResponse resp)
            throws ServletException, IOException {
        // Request only the first 20 results on a page, ordered by price, then name, then id:
        Pageable pageRequest = Pageable.size(20).sortBy(Sort.desc("price"), Sort.asc("name"), Sort.asc("id"));
        Page<Product> page1 = products.findByNameIgnoreCaseContains(searchFor, pageRequest);
    }
}

For more information, refer to the the draft of the Jakarta Data specification and the corresponding Javadoc.

We welcome your feedback on Jakarta Data and it will be helpful as the specification develops further. Let us know what you think, or get involved directly in the specification on GitHub.

Try it now

To try out beta features, update your build tools to pull the Open Liberty All Beta Features package instead of the main release. The beta works with Java SE 20, Java SE 17, Java SE 11, and Java SE 8.

If you’re using Maven, you can install the All Beta Features package using:

<plugin>
    <groupId>io.openliberty.tools</groupId>
    <artifactId>liberty-maven-plugin</artifactId>
    <version>RELEASE</version>
    <configuration>
        <runtimeArtifact>
          <groupId>io.openliberty.beta</groupId>
          <artifactId>openliberty-runtime</artifactId>
          <version>23.0.0.7-beta</version>
          <type>zip</type>
        </runtimeArtifact>
    </configuration>
</plugin>

<dependency>
  <groupId>jakarta.data</groupId>
  <artifactId>jakarta-data-api</artifactId>
  <version>1.0.0-b2</version>
</dependency>

Or for Gradle:

dependencies {
    libertyRuntime group: 'io.openliberty.beta', name: 'openliberty-runtime', version: '[23.0.0.7-beta,)'
}

Or if you’re using container images:

FROM icr.io/appcafe/open-liberty:beta

Or take a look at our Downloads page.

For more information on using a beta release, refer to the Installing Open Liberty beta releases documentation.

We welcome your feedback

Let us know what you think on our mailing list. If you hit a problem, post a question on StackOverflow. If you hit a bug, please raise an issue.

How to package your cloud-native Java application for rapid startup

Thu, 29 Jun 2023 00:00:00 +0000

Did you know you can repackage your cloud-native Java applications to start in milliseconds, without compromising throughput, memory, development-production parity, or Java language features? And with little to no refactoring of the application code? Here’s how…

The need for speed at startup

In serverless environments, scale-to-zero can help reduce the overall cloud costs for deployed applications by shutting down unneeded application instances when no ongoing requests exist. When activity picks up for the application, new instances can start quickly, without introducing noticeable delays for the application end user.

Despite improvements to JDK technology that make it start in less than 1 second, like class data sharing and dynamic AOT compilation, it still cannot start fast enough to support scale-to-zero. However, the JDK is important for optimizing throughput and memory, ensuring development-production parity, and enabling a full range of Java language features. So how do we improve startup time while also benefiting from running on the full JDK?

The InstantOn capability in the Open Liberty runtime uses the IBM Semeru JDK and a Linux technology called Checkpoint/Restore in Userspace (CRIU) to take a checkpoint, or a point-in-time snapshot, of the application process. This checkpoint can then be restored very quickly to bring the application process back into the state it was in when the checkpoint was taken. The application can be restored multiple times because Open Liberty and Semeru JDK preserve the uniqueness of each restored process in containers. Each restored application process runs without first having to go through the whole startup sequence, saving up to 90% of startup time (depending on your application). InstantOn requires very little modification of your Java application to make this improvement happen.

The following diagram demonstrates how the checkpoint that is taken during the container image build can be used to rapidly start multiple instances of an application in production by restoring them to the checkpointed phase of the application process.

InstantOn cannot be used outside of a container image build. An application container image provides a consistent environment, which is required to ensure a reliable restore of an Open Liberty application process. Since the InstantOn checkpoint is included in the last layer of the application container image, the resources in the underlying layers of the image do not change from the time the checkpoint is taken to the time the image is restored.

The following tutorial walks you through containerizing your application using the Open Liberty Java runtime, InstantOn, IBM Semeru JDK, and Podman container tools running on Linux. For general information about containerizing applications with Open Liberty, see the Containerizing microservices with Podman guide.

Prerequisites to checkpoint/restore a containerized application

Currently, Open Liberty version 23.0.0.6 or later supports running with InstantOn only on x86-64/amd64 architectures. All our testing was done on RHEL 9.0 and Ubuntu 22.04 but it might also be possible to run on other Linux distributions and versions if they have the following prerequisites:

The kernel must support the Linux CAP_CHECKPOINT_RESTORE capability. This capability was introduced in kernel version 5.9.
The latest available version of Podman for the Linux distribution must be installed.
The Linux distribution must allow the execution of privileged container builds by using Podman or Docker.

For more information about the runtime and host build system prerequisites, see the Open Liberty InstantOn documentation.

Create an application WAR file

If you don’t have an application of your own handy, you can follow along with an example application from the Getting started with Open Liberty guide.

First, clone the Git repository for the guide:

git clone https://github.com/openliberty/guide-getting-started.git
cd guide-getting-started

Then, build the application, which is in the finish/ directory, and deploy it to Open Liberty:

cd finish
mvn liberty:run

When you see the following message, your Open Liberty instance is ready:

The defaultServer server is ready to run a smarter planet.

Check out the service at the http://localhost:9080/dev/system/properties URL. Stop the running Open Liberty instance by pressing CTRL+C in the command-line session where you started Open Liberty.

Lastly, build the WAR for the application:

mvn package

This command builds a target/guide-getting-started.war archive. We can now include this WAR in a container image that uses the InstantOn feature.

Testing the startup time of your application

For comparison of how long it takes your Open Liberty application container image to start both with and without InstantOn, we describe how to build the container image without InstantOn first. Then, we describe how to build with InstantOn and run the resulting containers.

Containerizing the Open Liberty application without InstantOn

Build the application container image without InstantOn:

podman build -t getting-started .

This command creates the getting-started container image without any checkpoint image.

Run this application container:

podman run --name getting-started --rm -p 9080:9080 getting-started

Note the amount of time Open Liberty takes to report it is started and check out the service running in the container at the http://localhost:9080/dev/system/properties URL. After you finish checking out the application, stop the running container by pressing CTRL+C in the command-line session where you ran the podman run command.

Containerizing the Open Liberty application with InstantOn

The Open Liberty container image contains the prerequisites for building an application container image with a checkpointed runtime process. Applications can use the Open Liberty image as a base to build their own application container images and from that, create their own application container image with a checkpointed process.

Build the application container image and checkpoint the application

An InstantOn checkpoint is created by starting the Open Liberty runtime during the application container image build step. During this startup, the runtime processes the configuration, loads all the enabled features, and starts processing the configured application. Depending on the needs of your application, you can choose one of two specific phases during Open Liberty startup at which to checkpoint the process. You must configure the Dockerfile to specify your chosen phase (as we show later).

The official Open Liberty images from the IBM Container Registry (ICR) include all the prerequisites that are needed for InstantOn to checkpoint an application process. For this example, the getting-started application container image is using the icr.io/appcafe/open-liberty:full-java11-openj9-ubi image from ICR as the parent image. Currently, InstantOn is supported only with the Java 11 and Java 17-based UBI images of Open Liberty.

Update the application Dockerfile by adding a RUN command for the checkpoint.sh script to the end of the file, as shown in the following example:

FROM icr.io/appcafe/open-liberty:full-java11-openj9-ubi
ARG VERSION=1.0
ARG REVISION=SNAPSHOT
LABEL \
  org.opencontainers.image.authors="Your Name" \
  org.opencontainers.image.vendor="IBM" \
  org.opencontainers.image.url="local" \
  org.opencontainers.image.source="https://github.com/OpenLiberty/guide-getting-started" \
  org.opencontainers.image.version="$VERSION" \
  org.opencontainers.image.revision="$REVISION" \
  vendor="Open Liberty" \
  name="system" \
  version="$VERSION-$REVISION" \
  summary="The system microservice from the Getting Started guide" \
  description="This image contains the system microservice running with the Open Liberty runtime."

COPY --chown=1001:0 src/main/liberty/config/ /config/
COPY --chown=1001:0 target/*.war /config/apps/

RUN configure.sh
RUN checkpoint.sh afterAppStart

This configuration adds the application process checkpoint as the last layer of the application container image. The checkpoint.sh script allows you to specify either afterAppStart or beforeAppStart to indicate which phase of the startup performs the process checkpoint.

Two options are available to determine whether the checkpoint occurs before or after the application itself starts:

beforeAppStart: The checkpoint happens after processing the configured application metadata. If the application has any components that get run as part of the application starting, the checkpoint is taken before executing any code from the application. This option is the earliest checkpoint phase that is offered by InstantOn.
afterAppStart: This option is the latest phase where a checkpoint can happen, so it has the potential to provide the fastest startup time when restoring the application instance. The checkpoint happens after all configured applications are reported as started. This phase happens before opening any ports for listening to incoming requests for the applications.

The afterAppStart phase typically provides the quickest startup time for an application, but it also might cause some application code to run before the server process checkpoint happens. Since the getting-started application used in this tutorial does not do anything in its startup logic that would cause problems in restoring, we can use the afterAppStart phase for it.

For InstantOn to take a checkpoint of and restore a process, the CRIU binary requires additional Linux capabilities. The Open Liberty container image includes the necessary capabilities already granted to the binary. However, the container must also have these capabilities granted when it is launched.

With podman, you can use the -–cap-add and --security-opt options to grant the container build the necessary capabilities to take a checkpoint during the container build step. The user who launches the Podman container must have the authority to grant it the necessary Linux capabilities, so you must run the following command as root or sudo:

podman build \
   -t dev.local/getting-started-instanton \
   --cap-add=CHECKPOINT_RESTORE \
   --cap-add=SYS_PTRACE\
   --cap-add=SETPCAP \
   --security-opt seccomp=unconfined .

The last instruction in the Dockerfile is to run the checkpoint.sh script. When you execute the previous Podman build command, it launches Open Liberty to perform the checkpoint at the phase specified in the Dockerfile. After the container process data is persisted, Open Liberty stops and the container image build completes. The produced application container image contains the checkpoint process data as the last layer of the container image. The output looks something like the following example:

Performing checkpoint --at=afterAppStart

Launching defaultServer (Open Liberty 23.0.0.6/wlp-1.0.78.cl230620230612-1100) on Eclipse OpenJ9 VM, version 11.0.19+7 (en_US)
[AUDIT   ] CWWKE0001I: The server defaultServer has been launched.
[AUDIT   ] CWWKG0093A: Processing configuration drop-ins resource: /opt/ol/wlp/usr/servers/defaultServer/configDropins/defaults/keystore.xml
[AUDIT   ] CWWKG0093A: Processing configuration drop-ins resource: /opt/ol/wlp/usr/servers/defaultServer/configDropins/defaults/open-default-port.xml
[AUDIT   ] CWWKZ0058I: Monitoring dropins for applications.
[AUDIT   ] CWWKZ0001I: Application guide-getting-started started in 1.886 seconds.
[AUDIT   ] CWWKC0451I: A server checkpoint "afterAppStart" was requested. When the checkpoint completes, the server stops.

Run the InstantOn application image

Run the getting-started-instanton container with the following command:

podman run \
  --rm \
  --cap-add=CHECKPOINT_RESTORE \
  --cap-add=SETPCAP \
  --security-opt seccomp=unconfined \
  -p 9080:9080 \
  getting-started-instanton

The --cap-add options grant the container the two Linux capabilities that CRIU requires to restore the application process. When Open Liberty restores the application process, it logs the following messages:

[AUDIT   ] Launching defaultServer (Open Liberty 23.0.0.6/wlp-1.0.78.cl230620230612-1100) on Eclipse OpenJ9 VM, version 11.0.19+7 (en_US)
[AUDIT   ] CWWKZ0001I: Application guide-getting-started started in 0.233 seconds.
[AUDIT   ] CWWKT0016I: Web application available (default_host): http://850ba43df239:9080/dev/
[AUDIT   ] CWWKT0016I: Web application available (default_host): http://850ba43df239:9080/metrics/
[AUDIT   ] CWWKT0016I: Web application available (default_host): http://850ba43df239:9080/health/
[AUDIT   ] CWWKT0016I: Web application available (default_host): http://850ba43df239:9080/ibm/api/
[AUDIT   ] CWWKC0452I: The Liberty server process resumed operation from a checkpoint in 0.283 seconds.
[AUDIT   ] CWWKF0012I: The server installed the following features: [cdi-4.0, distributedMap-1.0, jndi-1.0, json-1.0, jsonb-3.0, jsonp-2.1, monitor-1.0, mpConfig-3.0, mpHealth-4.0, mpMetrics-5.0, restfulWS-3.1, restfulWSClient-3.1, ssl-1.0, transportSecurity-1.0].
[AUDIT   ] CWWKF0011I: The defaultServer server is ready to run a smarter planet. The defaultServer server started in 0.297 seconds.

If Open Liberty fails to restore the checkpoint process, it recovers by launching without the checkpoint image and logs the following message:

CWWKE0957I: Restoring the checkpoint server process failed. Check the /logs/checkpoint/restore.log log to determine why the checkpoint process was not restored. Launching the server without using the checkpoint image.

Check how long it took for Open Liberty to start and compare this to the time it took without InstantOn.

Performance results

InstantOn improves startup time of Open Liberty applications significantly by restoring the process from the checkpointed state. The improvement in the time to first response (i.e. the time taken to serve the first request) is also impressive but obviously more of the application logic runs after the restore in that case. We measured both metrics for multiple applications running in containers and using the afterAppStart checkpoint phase.

Pingperf is a very simple ping-type application involve a single REST endpoint.
Rest crud is a bit more complicated, and involves JPA and a remote database.
AcmeAir Microservice Main uses the MicroProfile features.

These experiments show a healthy improvement in startup times for all 3 applications and the time to first response is also improved by up to 8.8x when compared with normal JVM mode without InstantOn.^[1]

Summary

This post describes how to configure your cloud-native application to start almost immediately by using the Open Liberty InstantOn feature to produce an application container image. The key value proposition of InstantOn is that you can repackage your cloud-native Java applications to start in milliseconds, without compromising on throughput, memory, development-production parity, or Java language features. This feature is now available in Open Liberty 23.0.0.6 on the X86-64/AMD64 platforms running in the public cloud AWS EKS and Azure AKS environments.

In the future, we are planning to broaden our platform coverage and expand to be able to run in more managed public and hybrid cloud environments. We also intend to explore supporting InstantOn with an even larger set of Open Liberty features. For more details about Open Liberty InstantOn, see the Faster startup for containerized applications with Open Liberty InstantOn documentation, which links to more elaborate discussion on known limitations and information on the Semeru JDK support for this feature.

1. These experiments were run on a 24-core Linux X86-64 system, and taskset -c was used to allocate 4 cores to the Open Liberty process running in containers in each case. Startup time is measured from the time the Open Liberty server startup is initiated to the time the server is ready to accept requests, as denoted by The <server name> server is ready to run a smarter planet. message in the messages.log. The time it takes to start the container itself is also included in the results shown. InstantOn versus normal startup times for these applications are shown here in milliseconds. Your results might vary based on your environment, hardware and software installed on your system, and other factors.

InstantOn startup and Liberty Tools in Open Liberty 23.0.0.6

Tue, 27 Jun 2023 00:00:00 +0000

Open Liberty 23.0.0.6 adds the exciting Liberty InstantOn capability! With InstantOn, your applications can start in milliseconds, without compromising on throughput, memory, development-production parity, or Java language features. We are also excited to announce the release of the Liberty Tools v23.0.6, which makes Liberty development even faster by providing various development comforts like hover-over, quick fix, and diagnostic support. This release also provides many significant bug fixes, including one that addresses a CVE in the MicroProfile GraphQL features.

In Open Liberty 23.0.0.6:

Rapid startup with Liberty InstantOn
Liberty Development Tools
Security Vulnerability (CVE) Fixes
Notable bug fixes

Check out previous Open Liberty GA release blog posts.

Join our live webinars with the Open Liberty development team. Get updates and answers to your questions. The webinars are scheduled to accommodate different timezones and are similar in content. Register here to join live or to access the recordings later:

Run your apps using 23.0.0.6

If you’re using Maven, here are the coordinates:

<dependency>
    <groupId>io.openliberty</groupId>
    <artifactId>openliberty-runtime</artifactId>
    <version>23.0.0.6</version>
    <type>zip</type>
</dependency>

Or for Gradle:

dependencies {
    libertyRuntime group: 'io.openliberty', name: 'openliberty-runtime', version: '[23.0.0.6,)'
}

Or if you’re using container images:

FROM icr.io/appcafe/open-liberty

Or take a look at our Downloads page.

Rapid startup with Liberty InstantOn

Performance is one of the core focuses and differentiators of the Liberty runtime. As far back as 2019, Liberty was able to start up in ~1sec. Since then, Liberty has continued to pursue even faster startup, and this focus on performance has resulted in the InstantOn capability. Liberty InstantOn enables your applications to start in milliseconds, without compromising on throughput, memory, development-production parity, or Java language features.

To reduce the cost of running applications in the cloud, it is ideal to run the application only when it is needed. Unneeded application instances should be stopped. As soon as activity increases again, a new application instance needs to start up quickly and respond to incoming requests efficiently. This is known as scale-to-zero. Applications that take multiple seconds to start cannot scale-to-zero without introducing high latency for the application user.

InstantOn uses the Checkpoint/Restore In Userspace (CRIU) feature of the Linux kernel to take a checkpoint of the JVM that can be restored later. With InstantOn, the application is developed as normal, and then InstantOn makes a checkpoint of the application process when the application container image is built. When the application is restored, it runs in the same JVM, which provides complete parity between development and production. Because the checkpoint process takes only seconds, your CI/CD process is barely affected. The restoration of the image takes only milliseconds, allowing your applications to quickly scale up and down, which provides cost benefits without any negative impacts on the end users.

InstantOn supports Jakarta EE Web Profile versions 8.0 and later, MicroProfile versions 4.1 and later, as well as several other Liberty features. For more information, see the How to package your cloud-native Java application for rapid startup blog post and the Faster startup with InstantOn documentation.

Liberty Tools

The Liberty Tools v23.0.6 are now available! Some highlights include diagnostic and hover support for MicroProfile (3.x and later) and Jakarta EE Web Profile (9.x and later) APIs, as well as various Liberty config files. The Liberty Tools are available for Visual Studio Code, IntelliJ IDEA, and Eclipse IDE.

To get started with the Liberty Tools, you can obtain the link to install the tools for your favorite IDE from the Get started with Open Liberty page.

For more information, see the Develop with Liberty Tools documentation.

Security vulnerability (CVE) fixes in this release

CVE	CVSS Score	Vulnerability Assessment	Versions Affected	Notes
CVE-2023-28867	7.5	Denial of service	17.0.0.3 - 23.0.0.5	Affects the mpGraphQL-1.0 and mpGraphQL-2.0 features

CVE

CVSS Score

Vulnerability Assessment

Versions Affected

Notes

CVE-2023-28867

7.5

Denial of service

17.0.0.3 - 23.0.0.5

Affects the mpGraphQL-1.0 and mpGraphQL-2.0 features

For a list of past security vulnerability fixes, see the Security vulnerability (CVE) list.

Notable bugs fixed in this release

We’ve spent some time fixing bugs. The following sections describe just some of the issues resolved in this release. If you’re interested, here’s the full list of bugs fixed in 23.0.0.6.

JSF Container’s Application.getWrapped returns null

The JSF Container features return null when javax.faces.application.Application.getWrapped method is called.

This issue has been resolved and the correct wrapped object is returned.

transport close timing issue when streams are closing and a close/goaway frame comes in

Since Http/2 and webSocket are full duplex connections, multiple threads might be working at the same time on the same connection. A timing window existed where one thread is closing down the connection, gets interrupted, and another thread closes the connection. Then the first thread wakes back up to resources that have already been freed.

The error may produce an exception similar to the following:

java.io.IOException: Request not read yet
> at com.ibm.ws.http.channel.internal.inbound.HttpInboundServiceContextImpl.finishResponseMessage(HttpInboundServiceContextImpl.java:907)
> at com.ibm.ws.http.channel.internal.inbound.HttpInboundServiceContextImpl.finishResponseMessage(HttpInboundServiceContextImpl.java:989)
> at com.ibm.ws.http.channel.internal.inbound.HttpInboundLink.close(HttpInboundLink.java:678)
> at com.ibm.wsspi.channelfw.base.InboundApplicationLink.close(InboundApplicationLink.java:105)
> at com.ibm.ws.http.dispatcher.internal.channel.HttpDispatcherLink.close(HttpDispatcherLink.java:244)
> at com.ibm.ws.http.dispatcher.internal.channel.HttpDispatcherLink.finish(HttpDispatcherLink.java:1022)
> at com.ibm.ws.webcontainer.osgi.DynamicVirtualHost$2.run(DynamicVirtualHost.java:293)
> at com.ibm.ws.http.dispatcher.internal.channel.HttpDispatcherLink$TaskWrapper.run(HttpDispatcherLink.java:1159)
> at com.ibm.ws.http.dispatcher.internal.channel.HttpDispatcherLink.wrapHandlerAndExecute(HttpDispatcherLink.java:428)
> at com.ibm.ws.http.dispatcher.internal.channel.HttpDispatcherLink.ready(HttpDispatcherLink.java:387)
> at com.ibm.ws.http.channel.internal.inbound.HttpInboundLink.handleDiscrimination(HttpInboundLink.java:566)
> at com.ibm.ws.http.channel.internal.inbound.HttpInboundLink.handleNewRequest(HttpInboundLink.java:500)
> at com.ibm.ws.http.channel.internal.inbound.HttpInboundLink.processRequest(HttpInboundLink.java:360)
> at com.ibm.ws.http.channel.internal.inbound.HttpInboundLink.ready(HttpInboundLink.java:327)
> at com.ibm.ws.tcpchannel.internal.NewConnectionInitialReadCallback.sendToDiscriminators(NewConnectionInitialReadCallback.java:167)
> at com.ibm.ws.tcpchannel.internal.NewConnectionInitialReadCallback.complete(NewConnectionInitialReadCallback.java:75)
> at com.ibm.ws.tcpchannel.internal.WorkQueueManager.requestComplete(WorkQueueManager.java:504)
> at com.ibm.ws.tcpchannel.internal.WorkQueueManager.attemptIO(WorkQueueManager.java:574)
> at com.ibm.ws.tcpchannel.internal.WorkQueueManager.workerRun(WorkQueueManager.java:958)
> at com.ibm.ws.tcpchannel.internal.WorkQueueManager$Worker.run(WorkQueueManager.java:1047)
> at com.ibm.ws.threading.internal.ExecutorServiceImpl$RunnableWrapper.run(ExecutorServiceImpl.java:238)
> at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:834)

This issue has been resolved by ensuring a thread doesn’t attempt to close a connection that has already been closed by another thread.

Posting Form-Data with the new Jakarta EE 10 Multipart Support fails

When posting multipart/form-data to a REST endpoint using the @FormParam annotation for an EntityPart or InputStream parameter, the request fails with a 400 Bad Request response, and the following exception is logged:

jakarta.ws.rs.BadRequestException: RESTEASY003320: Failed processing arguments of public java.lang.String com.demo.rest.TestResource.upload(java.lang.String,jakarta.ws.rs.core.EntityPart) throws java.io.IOException
at org.jboss.resteasy.core.MethodInjectorImpl.injectArguments(MethodInjectorImpl.java:120)
Caused by: java.lang.UnsupportedOperationException: SRVE8020E: Servlet does not accept multipart requests
at com.ibm.ws.webcontainer.srt.SRTServletRequest.prepareMultipart(SRTServletRequest.java:3838)

During deployment, when using an EntityPart parameter, the following warning is logged:

SROAP04005: Could not find schema class in index: jakarta.ws.rs.core.EntityPart

This issue has been resolved and the @FormParam annotation can now be used with EntityParts.

server version command ignores JAVA_HOME set in server’s server.env

The server version <serverName> command ignores the JAVA_HOME variable that is set in the server’s server.env file. Instead it prints out the Java version info of the Java installation set by JAVA_HOME variable in shell environment (bash).

This issue has been resolved and the server version command now correctly identifies the Java version as specified in the server.env file.

Get Open Liberty 23.0.0.6 now

Available through Maven, Gradle, Docker, and as a downloadable archive.

Enterprise Kotlin: Kotlin and Jakarta EE

Thu, 01 Jun 2023 00:00:00 +0000

Mads Opheim investigates two questions: 1. can you use Jakarta EE and Kotlin in combination, and 2. should you?

MicroProfile 6 and Jakarta EE 10 guide updates in Open Liberty 23.0.0.5

Tue, 30 May 2023 00:00:00 +0000

Concurrent with the Open Liberty 23.0.0.5 release, 44 of the Open Liberty guides have been updated to make use of the latest MicroProfile 6 and Jakarta EE 10 specifications. Various bugs have been fixed as part of this release.

In Open Liberty 23.0.0.5:

44 guides updated to use MicroProfile 6 and Jakarta EE 10
Notable bug fixes

Check out previous Open Liberty GA release blog posts.

Run your apps using 23.0.0.5

If you’re using Maven, here are the coordinates:

<dependency>
    <groupId>io.openliberty</groupId>
    <artifactId>openliberty-runtime</artifactId>
    <version>23.0.0.5</version>
    <type>zip</type>
</dependency>

Or for Gradle:

dependencies {
    libertyRuntime group: 'io.openliberty', name: 'openliberty-runtime', version: '[23.0.0.5,)'
}

Or if you’re using container images:

FROM icr.io/appcafe/open-liberty

Or take a look at our Downloads page.

44 guides updated to use MicroProfile 6 and Jakarta EE 10

As Open Liberty features and functionality continue to grow, we continue to add new guides to openliberty.io on those topics to make their adoption as easy as possible. Existing guides also receive updates to address any reported bugs/issues, keep their content current, and expand what their topic covers.

Concurrent with the 23.0.0.5 release, the following 44 guides have been updated to use the latest MicroProfile 6 and Jakarta EE 10 specifications:

For the full list of Open Liberty guides, refer to the guides page.

Notable bugs fixed in this release

We’ve spent some time fixing bugs. The following sections describe just some of the issues resolved in this release. If you’re interested, here’s the full list of bugs fixed in 23.0.0.5.

Memory Leak in MicroProfile OpenAPI’s SchemaRegistry.current

A user reported a memory leak that occurred with each application restart, where 100MB of additional memory was used each time. The culprit ended up coming from MicroProfile OpenAPI’s SchemaRegistry class.

This issue has been reported upstream to SmallRye, and has also been fixed directly in Liberty.
HTTP/2 max frame size exceeded when compression is used

When compression is configured in the server.xml on an httpendpoint and http/2 is used, the http/2 max frame size may be exceeded, leading to a FRAME_SIZE_ERROR appearing in the server’s log.

This issue has been resolved and the http/2 response data is now split into multiple data frames to avoid sending a data frame larger than the http/2 max frame size of the client.

EntryNotFoundException thrown in federated registries when using custom input/output configuration

When running with federatedRegistries-1.0, it is possible to get an EntryNotFoundException when defining a non-identifier type property for the federated registries input/output mapping. This exception can occur in any of the com.ibm.ws.security.wim.registry.util.*Bridge classes, but the key is it originates from a BridgeUtils.getEntityByIdentifier call.

The following is an example stack:

com.ibm.websphere.security.EntryNotFoundException: CWIML1010E: The user registry operation could not be completed. The uniqueId = null and uniqueName = null attributes of the identifier object are either not valid or not defined in the back-end repository.
        at com.ibm.ws.security.registry.internal.UserRegistryWrapper.getGroupsForUser(UserRegistryWrapper.java:248)
        at web.UserRegistryServlet.handleMethodRequest(UserRegistryServlet.java:140)
        at web.UserRegistryServlet.doGet(UserRegistryServlet.java:174)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
        at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1258)
        ...

This issue has been resolved and the method no longer throws EntryNotFoundException.

requestTiming-1.0 causes elevated (or spiking) CPU performance due to the SlowRequestManager

When using the requestTiming-1.0 feature in OpenLiberty, the CPU usage is elevated. CPU impact correlates to CPU capacity.

This is more obvious when a lower threshold is set for the "slow request" threshold (i.e. e.g. <= 15s). Even so, may not encounter a noticeable impact depending on CPU capacity.

This is also more obvious if the request has a high hung threshold or if the request is hung indefinitely and can not be terminated by by the interruptHungRequest attribute (leading to an indefinite hang). This allows for a bigger window of opportunity to witness any CPU spikes/elevation.

This issue has been resolved and the elevated CPU usage no longer occurs.
Request Timing metrics not showing up with mpMetrics-5.0 (when used with requestTiming-1.0 feature).

When using the mpMetrics-5.0 and requestTiming-1.0 features, the request timing metrics are not being provided.

This issue has been resolved and the expected request timing metrics are now provided.

Get Open Liberty 23.0.0.5 now

Available through Maven, Gradle, Docker, and as a downloadable archive.

InstantOn and Jakarta Data in Open Liberty 23.0.0.5-beta

Tue, 16 May 2023 00:00:00 +0000

Open Liberty 23.0.0.5-beta includes the latest updates to our ongoing InstantOn functionality, which provides incredibly fast startup times. This beta release also includes the latest updates to the Jakarta Data preview.

For more information on InstantOn, refer to the New enhancements for Liberty InstantOn in 23.0.0.2-beta and Liberty InstantOn on Amazon EKS blog posts. For more information about the Jakarta Data preview, refer to the Jakarta Data preview update in Open Liberty 23.0.0.4-beta blog post.

If you’d like to know what else the team is currently considering or actively working on, refer to the Open Liberty Roadmap and the in progress work items.

Try it now

To try out these features, update your build tools to pull the Open Liberty All Beta Features package instead of the main release. The Open Liberty beta releases include the mentioned beta features along with all GA features. The beta works with Java SE 20, Java SE 17, Java SE 11, and Java SE 8.

If you’re using Maven, you can install the All Beta Features package using:

<plugin>
    <groupId>io.openliberty.tools</groupId>
    <artifactId>liberty-maven-plugin</artifactId>
    <version>RELEASE</version>
    <configuration>
        <runtimeArtifact>
          <groupId>io.openliberty.beta</groupId>
          <artifactId>openliberty-runtime</artifactId>
          <version>23.0.0.5-beta</version>
          <type>zip</type>
        </runtimeArtifact>
    </configuration>
</plugin>

You must also add dependencies to your pom.xml file for the beta version of the APIs that are associated with the beta features that you want to try. For example, for Jakarta Data beta 2, you would include:

<dependency>
  <groupId>jakarta.data</groupId>
  <artifactId>jakarta-data-api</artifactId>
  <version>1.0.0-b2</version>
</dependency>

Or for Gradle:

dependencies {
    libertyRuntime group: 'io.openliberty.beta', name: 'openliberty-runtime', version: '[23.0.0.5-beta,)'
}

Or if you’re using container images:

FROM icr.io/appcafe/open-liberty:beta

Or take a look at our Downloads page.

For more information on using a beta release, refer to the Installing Open Liberty beta releases documentation.

We welcome your feedback

Let us know what you think on our mailing list. If you hit a problem, post a question on StackOverflow. If you hit a bug, please raise an issue.

Jakarta Data preview update in Open Liberty 23.0.0.4-beta

Tue, 18 Apr 2023 00:00:00 +0000

Open Liberty 23.0.0.4-beta updates the Jakarta Data preview with an option to combine multiple ways to specify ordering and sorting.

The Open Liberty 23.0.0.4-beta includes the following beta features (along with all GA features):

A Very Early Preview of Jakarta Data (Beta 2)

A Very Early Preview of Jakarta Data (Beta 2)

In Open Liberty 23.0.0.2-beta, we introduced a very early preview of Jakarta Data, which aims to standardize the popular Data Repository pattern across relational and NoSQL databases.

This Jakarta Data beta update allows you to combine multiple ways of specifying ordering and sorting, defining a precedence. Sorting that is defined by the OrderBy annotation or query-by-method keyword is applied first, followed by Sort parameters on the method or Pageable.

Building on from the code snippet provided in the original preview, the following example uses both OrderBy and Sort:

public class Product { // entity
    public long id;
    public String name;
    public float price;
}

@Repository
public interface Products {
    Product findById(long productId);

    @OrderBy("price")
    List<Product> findByNameContains(String searchFor);

    @OrderBy("price")
    Page<Product> findByNameIgnoreCaseContains(String searchFor, Pageable pageRequest);

    @Query("UPDATE Product o SET o.price = o.price - (?2 * o.price) WHERE o.id = ?1")
    boolean discount(long productId, float discountRate);

    void save(Product p);
}

public class MyServlet extends HttpServlet {
    @Inject
    Products products;

    protected void doGet(HttpServletRequest req, HttpServletResponse resp)
            throws ServletException, IOException {
        // Find all matching:
        List<Product> all = products.findByNameContains(searchFor);

        // Request only the first page, ordered by price, then name, then id:
        Pageable pageRequest = Pageable.size(20).sortBy(Sort.asc("name"), Sort.asc("id"));
        Page<Product> page1 = products.findByNameIgnoreCaseContains(searchFor, pageRequest);
    }
}

Jakarta Data has not yet defined a standard configuration model. For now, the Open Liberty beta reuses the existing defaultDatabaseStore configuration for Jakarta Data, which defaults to the DefaultDataSource data source. As a result, the beta of Jakarta Data is currently limited to a single data source. This of course will change as the specification defines more of a configuration model. The data-1.0 Liberty beta feature makes the Jakarta Data API available, and you also need a feature for Jakarta Persistence or JDBC (or at some point in the future, Jakarta NoSQL).

Example server.xml configuration:

<server>
  <featureManager>
    <feature>data-1.0</feature>
    <feature>persistence-3.1</feature> <!-- could use jdbc-4.3 instead -->
    <feature>servlet-6.0</feature> <!-- the example includes a servlet -->
  </featureManager>

  <dataSource id="DefaultDataSource">
    <jdbcDriver libraryRef="PostgreSQL"/>
    <properties.postgresql databaseName="testdb" serverName="localhost" portNumber="5432"/>
    <containerAuthData user="dbuser1" password="dbpwd1"/>
  </dataSource>

  <library id="PostgreSQL">
    <file name="${shared.resource.dir}/jdbc/postgresql.jar"/>
  </library>

  <!-- optional because the following are all defaulted: -->
  <databaseStore id="defaultDatabaseStore" createTables="true" dropTables="false"
          tablePrefix="WLP" dataSourceRef="DefaultDataSource"/>
</server>

You can find the 1.0.0-b2 beta release of Jakarta Data on Maven, which corresponds to the Open Liberty 23.0.0.4 beta.

<dependency>
  <groupId>jakarta.data</groupId>
  <artifactId>jakarta-data-api</artifactId>
  <version>1.0.0-b2</version>
</dependency>

For more information, refer to the the draft of the Jakarta Data specification and the corresponding Javadoc.

Try it now

If you’re using Maven, you can install the All Beta Features package using:

<plugin>
    <groupId>io.openliberty.tools</groupId>
    <artifactId>liberty-maven-plugin</artifactId>
    <version>RELEASE</version>
    <configuration>
        <runtimeArtifact>
          <groupId>io.openliberty.beta</groupId>
          <artifactId>openliberty-runtime</artifactId>
          <version>23.0.0.4-beta</version>
          <type>zip</type>
        </runtimeArtifact>
    </configuration>
</plugin>

<dependency>
  <groupId>jakarta.data</groupId>
  <artifactId>jakarta-data-api</artifactId>
  <version>1.0.0-b2</version>
</dependency>

Or for Gradle:

dependencies {
    libertyRuntime group: 'io.openliberty.beta', name: 'openliberty-runtime', version: '[23.0.0.4-beta,)'
}

Or if you’re using container images:

FROM icr.io/appcafe/open-liberty:beta

Or take a look at our Downloads page.

For more information on using a beta release, refer to the Installing Open Liberty beta releases documentation.

We welcome your feedback

Let us know what you think on our mailing list. If you hit a problem, post a question on StackOverflow. If you hit a bug, please raise an issue.

Jakarta EE 10, MicroProfile 6, and Java SE 20 support in Open Liberty 23.0.0.3

Tue, 04 Apr 2023 00:00:00 +0000

We’re thrilled to announce the release of Open Liberty 23.0.0.3, one of the biggest releases of the runtime since its debut over 5 years ago! This release includes Jakarta EE 10 Platform, Web Profile, and, for the first time, Core Profile. Many new enhancements are added throughout most of the features that make up the profiles.

MicroProfile 6, which includes Jakarta EE Core Profile 10, also makes its formal debut in the 23.0.0.3 release. It includes the new MicroProfile Telemetry 1.0 feature as well as updates to the Metrics, OpenAPI, and JWT Authentication specifications.

Support for Java SE 20, the latest version as of this writing, is also introduced in the 23.0.0.3 release and provides various new features and changes. Many notable bug fixes are also included in this Open Liberty release.

In Open Liberty 23.0.0.3:

Jakarta EE 10 Core Profile, Web Profile, and Platform
MicroProfile 6.0
Support for Java SE 20
Notable bug fixes

Check out previous Open Liberty GA release blog posts.

Run your apps using 23.0.0.3

If you’re using Maven, here are the coordinates:

<dependency>
    <groupId>io.openliberty</groupId>
    <artifactId>openliberty-runtime</artifactId>
    <version>23.0.0.3</version>
    <type>zip</type>
</dependency>

Or for Gradle:

dependencies {
    libertyRuntime group: 'io.openliberty', name: 'openliberty-runtime', version: '[23.0.0.3,)'
}

Or if you’re using container images:

FROM icr.io/appcafe/open-liberty

Or take a look at our Downloads page, where we’ve added the Jakarta EE 10 and MicroProfile 6 packages.

Jakarta EE 10 Core Profile, Web Profile, and Platform

Jakarta EE 10 Core Profile, Web Profile and Platform are now officially supported in Open Liberty! We’d like to start by thanking all those who provided feedback throughout our various betas.

Jakarta EE 10 marks a major milestone. It is the first Jakarta release to provide updates to the specifications since Java EE 8 in 2017 and, therefore, the first to provide spec updates since the spec was taken over by the Eclipse Foundation. Among the many updates to existing specifications, it also introduces the Core Profile. The Core Profile is aimed at lightweight runtimes, like Open Liberty, that are optimized for running cloud-native Java microservices.

The following specifications make up the Jakarta Platform and the Core and Web profiles:

Jakarta EE Core Profile 10

Specification	Updates	Liberty Feature Documentation
Context and Dependency Injection 4.0 Lite	New	cdi-4.0
JSON Binding 3.0	Major update	jsonb-3.0
RESTful Web Services 3.1	Minor update	restfulWS-3.1, restfulWSClient-3.1
JSON Processing 2.1	Minor update	jsonp-2.1
Annotations 2.1 & Interceptors 2.1	Minor updates	cdi-4.0
Dependency Injection 2.0	Unchanged	cdi-4.0

Specification

Updates

Liberty Feature Documentation

Context and Dependency Injection 4.0 Lite

New

cdi-4.0

JSON Binding 3.0

Major update

jsonb-3.0

RESTful Web Services 3.1

Minor update

restfulWS-3.1, restfulWSClient-3.1

JSON Processing 2.1

Minor update

jsonp-2.1

Annotations 2.1 & Interceptors 2.1

Minor updates

cdi-4.0

Dependency Injection 2.0

Unchanged

cdi-4.0

Jakarta EE Web Profile 10

Specification	Updates	Liberty Feature Documentation
Jakarta EE Core Profile 10	New	See previous table
Authentication 3.0	Major update	appAuthentication-3.0
Context and Dependency Injection 4.0	Major update	cdi-4.0
Concurrency 3.0	Major update	concurrent-3.0
Expression Language 5.0	Major update	expressionLanguage-5.0
Faces 4.0	Major update	faces-4.0
Security 3.0	Major update	appSecurity-5.0
Servlet 6.0	Major update	servlet-6.0
Standard Tag Library 3.0	Major update	pages-3.1
Persistence 3.1	Minor update	persistence-3.1
Server Pages 3.1	Minor update	pages-3.1
WebSocket 2.1	Minor update	websocket-2.1
Bean Validation 3.0	No change	beanValidation-3.0
Debugging Support for Other Languages 2.0	No change	Not applicable
Enterprise Beans 4.0 Lite	No change	enterpriseBeansLite-4.0
Managed Beans 2.0	No change	managedBeans-2.0
Transactions 2.0	No change	Not applicable (see Javadoc)

Specification

Updates

Liberty Feature Documentation

Jakarta EE Core Profile 10

New

See previous table

Authentication 3.0

Major update

appAuthentication-3.0

Context and Dependency Injection 4.0

Major update

cdi-4.0

Concurrency 3.0

Major update

concurrent-3.0

Expression Language 5.0

Major update

expressionLanguage-5.0

Major update

Major update

Major update

Standard Tag Library 3.0

Major update

Minor update

Minor update

Minor update

No change

Debugging Support for Other Languages 2.0

No change

Not applicable

Enterprise Beans 4.0 Lite

No change

enterpriseBeansLite-4.0

Managed Beans 2.0

No change

managedBeans-2.0

Transactions 2.0

No change

Not applicable (see Javadoc)

Jakarta EE Platform 10

Specification	Updates	Liberty Feature Documentation
Jakarta EE Web Profile 10	Major update	See previous table
Authorization 2.1	Minor update	appAuthorization-2.1
Activation 2.1	Minor update	Not applicable (see Javadoc)
Batch 2.1	Minor update	batch-2.1
Connectors 2.1	Minor update	connectors-2.1
Mail 2.1	Minor update	mail-2.1
Messaging 3.1	Minor update	messaging-3.1
Enterprise Beans 4.0	No change	enterpriseBeans-4.0
XML Binding 4.0 (optional)	Major update	xmlBinding-4.0
XML Web Services 4.0 (optional)	Major update	xmlWS-4.0

Specification

Updates

Liberty Feature Documentation

Jakarta EE Web Profile 10

Major update

Minor update

Minor update

Not applicable (see Javadoc)

Minor update

Minor update

Minor update

Minor update

No change

XML Binding 4.0 (optional)

Major update

xmlBinding-4.0

XML Web Services 4.0 (optional)

Major update

xmlWS-4.0

Liberty provides convenience features for running all of the component specifications that are contained in the Jakarta EE 10 Web Profile (webProfile-10.0) and Jakarta EE 10 Platform (jakartaee-10.0). These convenience features enable you to rapidly develop applications using all of the APIs contained in their respective specifications. For Jakarta EE 10 features in the application client, use the jakartaeeClient-10.0 Liberty feature.

To enable the Jakarta EE Platform 10 features, add the jakartaee-10.0 feature to your server.xml file:

  <featureManager>
    <feature>jakartaee-10.0</feature>
  </featureManager>

Alternatively, to enable the Jakarta EE Web Profile 10 features, add the webProfile-10.0 feature to your server.xml file:

  <featureManager>
    <feature>webProfile-10.0</feature>
  </featureManager>

Although no convenience feature exists for the Core Profile, you can enable its equivalent by adding the following features to your server.xml file:

  <featureManager>
    <feature>jsonb-3.0</feature>
    <feature>jsonp-2.1</feature>
    <feature>cdi-4.0</feature>
    <feature>restfulWS-3.1</feature>
  </featureManager>

To run Jakarta EE 10 features on the Application Client Container, add the following entry in your application’s client.xml file:

  <featureManager>
    <feature>jakartaeeClient-10.0</feature>
  </featureManager>

For more information reference:

Jakarta EE Platform 10, Jakarta EE Web Profile 10, and Jakarta EE Core Profile 10 specifications.
Jakarta EE 10 Javadoc
Differences between Jakarta EE 10 and 9.1

MicroProfile 6.0

MicroProfile continues to innovate how the industry optimizes Java microservices. The MicroProfile 6.0 release enables applications to use MicroProfile APIs together with Jakarta EE Core Profile 10 along with various other new functions and improvements. The following specifications make up MicroProfile 6.0:

Specification	Updates	Liberty Feature Documentation
MicroProfile Telemetry 1.0	New	mpTelemetry-1.0
MicroProfile Metrics 5.0	Major update	mpMetrics-5.0
MicroProfile OpenAPI 3.1	Minor update	mpOpenAPI-3.1
MicroProfile JWT Authentication 2.1	Minor update	mpJwt-2.1
MicroProfile Config 3.0	Unchanged	mpConfig-3.0
MicroProfile Health 4.0	Unchanged	mpHealth-4.0
MicroProfile Rest Client 3.0	Unchanged	mpRestClient-3.0
MicroProfile Fault Tolerance 4.0	Unchanged	mpFaultTolerance-4.0
Jakarta EE Core Profile 10	New	See Core Profile table

Specification

Updates

Liberty Feature Documentation

MicroProfile Telemetry 1.0

New

mpTelemetry-1.0

MicroProfile Metrics 5.0

Major update

mpMetrics-5.0

MicroProfile OpenAPI 3.1

Minor update

mpOpenAPI-3.1

MicroProfile JWT Authentication 2.1

Minor update

mpJwt-2.1

MicroProfile Config 3.0

Unchanged

mpConfig-3.0

MicroProfile Health 4.0

Unchanged

mpHealth-4.0

MicroProfile Rest Client 3.0

Unchanged

mpRestClient-3.0

MicroProfile Fault Tolerance 4.0

Unchanged

mpFaultTolerance-4.0

Jakarta EE Core Profile 10

New

See Core Profile table

To enable all the MicroProfile 6 features, add the microProfile-6.0 feature to your server.xml file:

  <featureManager>
    <feature>microProfile-6.0</feature>
  </featureManager>

To find out more, take a look at the MicroProfile 6.0 specification, release, Javadoc, and Differences between MicroProfile 6.0 and 5.0.

Support for Java SE 20

Java 20 includes the following features and changes:

429: Scoped Values (Incubator)
432: Record Patterns (Second Preview)
433: Pattern Matching for switch (Fourth Preview)
434: Foreign Function & Memory API (Second Preview)
436: Virtual Threads (Second Preview)
437: Structured Concurrency (Second Incubator)

To use Java 20:

Download Java 20.
Obtain the 23.0.0.3 version of Open Liberty.
Edit your Liberty server.env file to point JAVA_HOME to your Java 20 installation.

For more information on Java 20, reference the Java 20 release notes page, API Javadoc page, download page and Java 20 migration guide.

To try out Java 20 preview features in Open Liberty, make sure to compile with --enable-preview and add the same parameter to your jvm.options file.

Notable bugs fixed in this release

We’ve spent some time fixing bugs. The following sections describe just some of the issues resolved in this release. If you’re interested, here’s the full list of bugs fixed in 23.0.0.3.

AcmeCA feature with revocation enabled can fail to initialize on certain OS and JDK combinations

When running with a hybrid JDK for MacOS with IBMJDK8 and the Automatic Certificate Management Environment (ACME) Support 2.0 feature with certification revocation checking enabled, the SSL/TLS endpoint can fail to complete initialization and will not be available for traffic.

The following NullPointerException is logged in the FFDC, indicating the failure in the initialization flow:

Exception = java.lang.NullPointerException
Source = com.ibm.ws.security.acme.internal.AcmeProviderImpl
probeid = 921
Stack Dump = java.lang.NullPointerException
at sun.security.provider.certpath.CertPathHelper.setDateAndTime(CertPathHelper.java:71)
at sun.security.provider.certpath.RevocationChecker.checkCRLs(RevocationChecker.java:525)
at sun.security.provider.certpath.RevocationChecker.checkCRLs(RevocationChecker.java:464)
at sun.security.provider.certpath.RevocationChecker.check(RevocationChecker.java:393)
at sun.security.provider.certpath.RevocationChecker.check(RevocationChecker.java:336)
at sun.security.provider.certpath.PKIXMasterCertPathValidator.validate(PKIXMasterCertPathValidator.java:125)
at sun.security.provider.certpath.PKIXCertPathValidator.validate(PKIXCertPathValidator.java:225)
at sun.security.provider.certpath.PKIXCertPathValidator.validate(PKIXCertPathValidator.java:145)
at sun.security.provider.certpath.PKIXCertPathValidator.engineValidate(PKIXCertPathValidator.java:84)
at java.security.cert.CertPathValidator.validate(CertPathValidator.java:304)
at com.ibm.ws.security.acme.internal.CertificateRevocationChecker.isRevoked(CertificateRevocationChecker.java:371)
....

This issue has been resolved and the endpoint successfully initializes and is available to service traffic.

Fix ClassCastException during the de-serialization of CDI Injected Event

A passivated (i.e. serializable) bean which has an injected jakarta.enterprise.event.Event (or javax equivalent) will not be properly restored. This can be encountered when session persistence is enabled and session data is serialized and de-serialized from a database. This causes the following FFDC to occur:

Stack Dump = java.lang.ClassCastException: cannot assign instance of org.jboss.weld.event.EventImpl$SerializationProxy to field org.apache.myfaces.flow.cdi.FlowScopeContextualStorageHolder.flowDestroyedEvent of type jakarta.enterprise.event.Event in instance of org.apache.myfaces.flow.cdi.FlowScopeContextualStorageHolder
        at java.base/java.io.ObjectStreamClass$FieldReflector.setObjFieldValues(ObjectStreamClass.java:2076)
        at java.base/java.io.ObjectStreamClass$FieldReflector.checkObjectFieldValueTypes(ObjectStreamClass.java:2039)
        at java.base/java.io.ObjectStreamClass.checkObjFieldValueTypes(ObjectStreamClass.java:1293)
        at java.base/java.io.ObjectInputStream.defaultCheckFieldValues(ObjectInputStream.java:2512)

This issue has been resolved and the CDI event objects is restored without errors.

JDBC DB2 values for queryDataSize need to be updated

When setting the queryDataSize for the DB2 DataSource to valid values for DB2 11.5.7+, the following error occurs:
```
[ERROR   ] CWWKG0075E: The value 10452991 is not valid for attribute `queryDataSize` of configuration element dataSource. The validation message was: Value "10452991" is out of range..
```
This issue has been resolved and the new queryDataSize range is correctly accepted.

Liberty server hangs randomly

A bug in OpenJ9 can cause the Liberty server to hang due to a deadlock when using JAX-RS. For example:

2LKMONINUSE      sys_mon_t:0x00007FCE3C16F258 infl_mon_t: 0x00007FCE3C16F2D8:
3LKMONOBJECT       org/apache/cxf/jaxrs/interceptor/CachedTime@0x00000000FBF1D0C8: Flat locked by "Default Executor-thread-8" (J9VMThread:0x0000000001B4BF00), entry count 1
3LKWAITERQ            Waiting to enter:
3LKWAITER                "Default Executor-thread-1" (J9VMThread:0x00000000006EB200)
3LKWAITER                "Default Executor-thread-3" (J9VMThread:0x0000000000718D00)
3LKWAITER                "Default Executor-thread-17" (J9VMThread:0x0000000002644B00)
3LKWAITER                "Default Executor-thread-19" (J9VMThread:0x0000000000346F00)
3LKWAITER                "Default Executor-thread-20" (J9VMThread:0x0000000000618300)
3LKWAITER                "Default Executor-thread-29" (J9VMThread:0x0000000002645700)
3LKWAITER                "Default Executor-thread-30" (J9VMThread:0x0000000002643F00)
3LKWAITER                "Default Executor-thread-39" (J9VMThread:0x00000000022FF900)
3LKWAITER                "Default Executor-thread-40" (J9VMThread:0x00000000022DAA00)
3LKWAITER                "Default Executor-thread-49" (J9VMThread:0x000000000216DE00)
3LKWAITER                "Default Executor-thread-50" (J9VMThread:0x00000000022FED00)
3LKWAITER                "Default Executor-thread-59" (J9VMThread:0x0000000001B74900)
3LKWAITER                "Default Executor-thread-60" (J9VMThread:0x0000000002178F00)
3LKWAITER                "Default Executor-thread-62" (J9VMThread:0x0000000001B72300)

"Default Executor-thread-8" J9VMThread:0x0000000001B4BF00, omrthread_t:0x00007FCE18012DF0, java/lang/Thread:0x00000000FBF99E78, state:B, prio=5
       (java/lang/Thread getId:0x4C, isDaemon:true)
       com/ibm/ws/classloading/internal/ThreadContextClassLoader(0x0000000086272FF8)
       (native thread ID:0x1A4, native priority:0x5, native policy:UNKNOWN, vmstate:B, vm thread flags:0x00000281)
       (native stack address range from:0x00007FCEA0FF6000, to:0x00007FCEA1036000, size:0x40000)
      CPU usage total: 3.272702139 secs, current category="Application"
Blocked on: java/lang/StringBuffer@0x00000000FBF99F10 Owned by: "Default Executor-thread-1" (J9VMThread:0x00000000006EB200, java/lang/Thread:0x00000000804DA638)
      Heap bytes allocated since last GC cycle=0 (0x0)
      Java callstack:
          at java/lang/StringBuffer.setLength(Bytecode PC:0(Compiled Code))
             (entered lock: java/lang/StringBuffer@0x00000000FBF99F10, entry count: 1)
          at org/apache/cxf/jaxrs/interceptor/CachedTime.updateTime(CachedTime.java:86)
          at org/apache/cxf/jaxrs/interceptor/CachedTime.getTimeAsString(CachedTime.java:134)

This issue has been mitigated in Liberty by removing the usage of SimpleDateFormat from CXF’s CachedTime class and the deadblock no longer occurs.

Get Open Liberty 23.0.0.3 now

Available through Maven, Gradle, Docker, and as a downloadable archive.

Open source cloud-native Java at DevNexus 2023!

Thu, 30 Mar 2023 00:00:00 +0000

What is DevNexus?

DevNexus is the longest-running and largest Java Conference in the US. It’s organised by a vibrant Java community and is being held in Atlanta this year from April 4-6. After the COVID-19 pandemic and its long-lasting effects, it’s wonderful to be able to come together again and have such a fantastic opportunity to reconnect with the wider Java community! And of course, we can’t wait to join too!

Several members of the Open Liberty team will be on site hosting sessions, quick labs, workshops, and running demonstrations at the IBM booth. If you’re going to be there, deciding which of the great sessions to see can be challenging. To help you decide, we’ve put together a useful summary of the sessions on MicroProfile, Jakarta EE, and Open Liberty.

Tuesday April 4th:

Workshop: Thriving in the cloud: Venturing beyond the 12 factors

In this workshop, you’ll get hands on with some of the most innovative and exciting open source cloud-native Java technologies, including Open Liberty, MicroProfile, Jakarta EE, Testcontainers, OpenJ9, and more! Emily Jiang, Rich Hagarty, Cindy High, and Harry Hoots will show you how to venture beyond the 12 factors to design and develop applications with the 15-factor app methodology. Don’t miss your chance to join this fantastic interactive learning opportunity!

Wednesday April 5th:

Talk: Jakarta EE for Spring Developers

Jakarta EE guru Ivar Grimstad teaches us how to convert our package namespace from javax.* to jakarta.* and why it matters to everyone in the Java ecosystem. A live coding demo will take us through the steps involved, and point out where to pay special attention.

Talk: Enhancing Java applications for the cloud

Tobi Ajila, a Java Runtime developer for the Eclipse OpenJ9 team in Canada, showcases how technologies like checkpoint/restore and remote JIT compilation can help minimize your application’s costs by boosting startup time and reducing memory footprint. Attendees will learn how these features integrate seamlessly with existing container technologies for simple, secure, and predictable deployments. Whether you are a cloud veteran or a newcomer, there will be lots to learn!

Deep Dive Session: Deep Dive MicroProfile 6.0 with Jakarta EE 10 Core Profile

Java champion Emily Jiang leads this deep dive session all around the exciting new updates from MicroProfile 6.0 and Jakarta EE 10. Included in this talk are some of the major updates within MicroProfile Metrics, which enables the adoption of Micrometer, and MicroProfile Telemetry, which consumes OpenTelemetry. Join this session to learn all about the observability standards for your microservices with a live demo on Open Liberty.

Thursday April 6th:

Talk: Jakarta EE 10 and Beyond

In this session, Reza Rahman (Principal Program Manager for Java on Azure at Microsoft) offers a brief tour of Jakarta EE 10 as well as a look at what the future might bring. If you’re up for a session that’s both useful and exploratory, then make sure you check out this session! As Reza says: “You should come to this session with your thinking caps on and your sleeves rolled up. There is much to help move forward together that really matters.”

Talk: Journey to cloud : leave no Java workload behind

IBMers Vijay Sundaresan and Mark Stoodley pull together the full landscape of exciting new technologies that can enable key cloud-native behaviours and characteristics, including fast startup times and low memory footprints. They’ll explain how many of these technologies and enhancements were developed at OpenJ9 and how they all fit together as a compelling and cooperative solution to optimize Java for the cloud. Interested? Then join what is sure to be an interesting session!

Panel Session: 5 years of Jakarta EE Panel: a look into the future

If you’re interested in a more interactive session, then be sure to bookmark this panel session! Jakarta EE experts (Ivar Grimstad, Tanja Obradovic, Emily Jiang, Jose Paumard, Mark Heckler, and Rudy De Busscher) will form the panel for this session, discussing the future of Jakarta EE with version 11 and beyond. Pop along to this session to ask those burning questions and gain exciting insight into where this fantastic open source technology is heading.

Talk: Jakarta EE integration testing

In this session, Rudy De Busscher explores scenarios of how you can use the Testcontainers framework to test your Jakarta EE application, including a remote debug session of your code.

Talk: Best practices for securing cloud-native applications

In this talk, chief architect for IBM Java Mark Stoodley will cover some best practices for authenticating users and authorizing them to access your microservice. He’ll provide an overview of microservice security, with samples based on the Open Liberty runtime. With the ever-growing importance of effectively securing our applications, this is sure to be a great session to attend.

IBM Booth:

As well as the numerous sessions during the conference, the Open Liberty team will also be manning the IBM booth in the exhibition hall. Stop by to get hands on with our quick labs (featuring InstantOn startup of cloud-native Java apps, MicroProfile and Jakarta EE), grab some awesome swag, and have a chat about all things OSS Java. We’d love to see you there!

This year, we’ll also have our exciting intergalactic booth challenge… The Open Liberty Space Rover Challenge. In this challenge, you’ll need to navigate the planets and get your rover safely to your destination in the stars. Take control of a spaceship and use hand signals to direct it’s flight from planet to planet. Climb the rankings on your way to become top cadet in Star Academy. Our Space Rover Challenge uses various technologies, including hardware and modern Java technology. While you’re with us, ask our developers about the underlying technologies they’ve used to create the demo, including OpenJ9, Jakarta EE, MicroProfile, and "the most flexible runtime in the cosmos", Open Liberty.

Check out IBM’s presence at DevNexus as well as the full schedule on the conference website.

Support for Java SE 20 in Open Liberty 23.0.0.3-beta

Thu, 23 Mar 2023 00:00:00 +0000

Open Liberty 23.0.0.3-beta introduces support for Java SE 20, which provides many exciting features and changes. This beta also includes all of Jakarta EE Platform 10 and MicroProfile 6.

The Open Liberty 23.0.0.3-beta includes the following beta features (along with all GA features):

Support for Java SE 20
Jakarta EE Platform 10 and MicroProfile 6

Support for Java SE 20

Try out Java 20, which includes the following features and changes:

429: Scoped Values (Incubator)
432: Record Patterns (Second Preview)
433: Pattern Matching for switch (Fourth Preview)
434: Foreign Function & Memory API (Second Preview)
436: Virtual Threads (Second Preview)
437: Structured Concurrency (Second Incubator)

By trying out the changes in Java 20 now, you get more time to review your applications, microservices, and runtime environments so you can be a step ahead when it becomes generally available.

Try Java 20 today:

Download the early access release of Java 20.
Install the 23.0.0.3-beta version of Open Liberty.
Edit your Liberty server.env file to point JAVA_HOME to your Java 20 installation.
Start testing!

For more information on Java 20, visit the Java 20 release notes page, API Javadoc page or download page.

Jakarta EE 10 and MicroProfile 6

This beta release also includes Jakarta EE Platform 10 and MicroProfile 6, which were first made available in the 22.0.0.13-beta. To find out more, reference the 22.0.0.13-beta blog post.

Try it now

If you’re using Maven, you can install the All Beta Features package using:

<plugin>
    <groupId>io.openliberty.tools</groupId>
    <artifactId>liberty-maven-plugin</artifactId>
    <version>RELEASE</version>
    <configuration>
        <runtimeArtifact>
          <groupId>io.openliberty.beta</groupId>
          <artifactId>openliberty-runtime</artifactId>
          <version>23.0.0.3-beta</version>
          <type>zip</type>
        </runtimeArtifact>
    </configuration>
</plugin>

<dependency>
    <groupId>org.eclipse.microprofile</groupId>
    <artifactId>microprofile</artifactId>
    <version>6.0-RC3</version>
    <type>pom</type>
    <scope>provided</scope>
</dependency>
<dependency>
    <groupId>jakarta.platform</groupId>
    <artifactId>jakarta.jakartaee-api</artifactId>
    <version>10.0.0</version>
    <scope>provided</scope>
</dependency>

Or for Gradle:

dependencies {
    libertyRuntime group: 'io.openliberty.beta', name: 'openliberty-runtime', version: '[23.0.0.3-beta,)'
}

Or take a look at our Downloads page.

For more information on using a beta release, refer to the Installing Open Liberty beta releases documentation.

We welcome your feedback

Let us know what you think on our mailing list. If you hit a problem, post a question on StackOverflow. If you hit a bug, please raise an issue.

Upgrade your cloud-native Java development experience with Liberty Tools for Eclipse IDE

Wed, 08 Mar 2023 00:00:00 +0000

Liberty Tools for Eclipse IDE provides a simplified yet powerful development experience. With capabilities like dev mode, Liberty config editing, and Jakarta EE and MicroProfile code assistance, you can code and manage your application without leaving your IDE.

Try it out today by installing from the Eclipse Marketplace.

Check out the YouTube video for a deep dive walk-through of Liberty Tools for Eclipse IDE.

Let’s dive in!

What is Liberty Tools?

Liberty Tools is the next generation IDE tooling for developing cloud-native Java applications with Liberty. It takes an app-centric approach, leveraging the capabilities of the Liberty Maven and Liberty Gradle plugins, so you no longer have to spend time creating and managing Liberty instances. By running dev mode behind the scenes, the Liberty runtime is automatically downloaded and started, and your app is built, packaged, and deployed to it. To save even more time, listeners detect any changes you make, and your app is automatically rebuilt and redeployed without having to restart the runtime.

Keeping in line with the app-centric design, Liberty Tools provides code assistance for both Jakarta EE and MicroProfile APIs. Code completion, hover descriptions, diagnostics and quick-fixes save time, reduce errors, and keep you focused on your code. Liberty Tools accomplishes this by integrating with the Language Server for Jakarta EE and the Language Server for MicroProfile, both open source projects that are continually adding new features and support.

While much of the runtime mechanics are automated with Liberty Tools, some runtime configuration is, of course, necessary. However, this process has been streamlined with config assistance for server.xml, bootstrap.properties, and server.env files. Rather than having to refer to the documentation to find the correct Liberty feature to add or the appropriate value to set for your specific logging attribute, Liberty Tools provides lists of options and descriptions, all without having to leave Eclipse.

Prefer another IDE? Liberty Tools for Eclipse IDE maintains functional parity with plugins for Visual Studio Code and Intellij IDEA.

Requirements

Liberty Tools for Eclipse IDE is designed to work with supported versions of both the IDE for Java EE Developers and the IDE for Java Developers. While Java 17 is needed to run the tool, you can choose a different version of Java to run your application.

Since Liberty Tools uses the Liberty Maven and Liberty Gradle plugins behind the scenes, these plugins must be configured in your application’s pom.xml or build.gradle files. Liberty Tools will also need to run the Maven or Gradle executable which can be accomplished by configuring the Maven and Gradle home in the tool’s preferences, or including a wrapper with the application.

Managing your applications

Any application in your Eclipse workspace that contains src/main/liberty/config/server.xml is automatically enabled to run with Liberty Tools. Actions are available to manage these apps such as Start, Stop, Debug and Run Tests, and you can run these actions from either the Liberty Dashboard or the Eclipse Run As menu.

Liberty Dashboard

The Liberty Dashboard consolidates the Liberty enabled applications in your workspace into a single view. To open the dashboard, click on the Open Liberty UFO icon on the top tray or press Alt + L. To run an action, simply right-click on an app in the list.

Liberty Tools offers the same set of actions in the Eclipse Run As menu that appears when you right click on a project in the Project Explorer view.

Starting your app

To start your application in dev mode, select either the Start or Start… actions. The latter opens a Run Configurations dialog box where you can add to the command-line parameters such as additional parameters to dev mode or configure the JRE to use when running the app. When a start action is selected, Liberty Tools opens a Terminal tab and starts dev mode.

The Start in container action will start dev mode in a local Docker container and requires 'docker' on the PATH.

Running tests

Tests are important for any application. Liberty Tools makes it easy to run your unit and integration tests by either selecting the Run tests action, or simply clicking Enter in the terminal. You can even view the results of your latest run by selecting View test reports.

Debugging your app

By default, the Liberty runtime is configured with port 7777 for debugging. However, this configuration requires that port to be available on your system and for you to manually attach a debugger. With Liberty Tools, you can start your app using the Debug action, which finds an available port and automatically attaches the Eclipse debugger to it.

Get coding!

Liberty Tools provides coding assistance for Jakarta EE and MicroProfile APIs, as well as select Liberty configuration files.

Jakarta EE

Code completion for Jakarta EE makes it easy to add classes and methods to your app. Just type CTRL + Space from within any Java file to choose from a list of available code snippets. Additionally, diagnostics flag errors and suggest quick-fixes to implement on the spot.

MicroProfile

Similar code completion is available for MicroProfile, as well as type-ahead suggestions and hover descriptions for MicroProfile Config properties. You can easily see what values are set for injected properties directly from your code and get lists of available variables and values to add to your configuration.

Liberty config editing

Liberty Tools streamlines the process of configuring the Liberty runtime through config completion for server.xml, bootstrap.properties and server.env files. Type CTRL + Space from within these files to get lists of suggested configuration elements, properties, and values.

Like what you see? Need support? Find us on Gitter, or open an issue or enhancement on Github.

Testing database connections and Jakarta Data preview in Open Liberty 23.0.0.2-beta

Tue, 21 Feb 2023 00:00:00 +0000

Open Liberty 23.0.0.2-beta includes several new enhancements for Liberty InstantOn that simplify the process for creating and restoring checkpoints. Admin Center’s Server Config tool receives new capability to test database connections, and a very early preview of Jakarta Data also makes its beta debut in this release. Also included in this beta is all of Jakarta EE Platform 10 and MicroProfile 6.

The Open Liberty 23.0.0.2-beta includes the following beta features (along with all GA features):

New enhancements for Liberty InstantOn
Testing database connections using Admin Center
A very early preview of Jakarta Data
Jakarta EE Platform 10 and MicroProfile 6

New enhancements for Liberty InstantOn

The Open Liberty 22.0.0.11-beta introduced InstantOn, an exciting new feature that provides incredibly fast startup times for MicroProfile and Jakarta EE applications. Since the initial beta release, we’ve made the following changes and enhancements to make it easier to create and deploy applications with Liberty InstantOn:

Removal of the features checkpoint phase
Reduced set of required Linux capabilities to checkpoint and restore
Simplified container image builds with InstantOn

To learn more about these changes and InstantOn, refer to the New enhancements for Liberty InstantOn in 23.0.0.2-beta blog post.

Testing database connections using Admin Center

Looking for a simple way to test your database connections? With this beta release, you can now validate your connections using the Liberty Admin Center feature. The connection test exercises the same code paths as your applications, giving you confidence in your server configuration. The Admin Center connection validation feature is enabled by REST APIs featured in the Testing database connections in Open Liberty apps with REST APIs blog post.

To enable database connection testing, the following minimum set of features must be present in your server configuration:

    <feature>adminCenter-1.0</feature>
    <feature>restConnector-2.0</feature>
    <feature>mpOpenApi-3.0</feature>

Although this example uses the mpOpenApi-3.0 feature, you can use any MicroProfile OpenAPI version that is compatible with your other features.

To provide an example, we’ll start by testing the server resource DefaultDataSource, which is configured to connect to a Derby database using container authentication with an authentication alias.

The following sample server.xml file enables the features to configure the Admin Center test connection function and configures the connection to the Derby database:

<server description="new server">

    <!-- Enable features -->
    <featureManager>
        <feature>adminCenter-1.0</feature>
        <feature>restConnector-2.0</feature>
        <feature>jdbc-4.3</feature>
        <feature>mpOpenApi-3.0</feature>
    </featureManager>

    <!-- To access this server from a remote client add a host attribute to the following element, e.g. host="*" -->
    <httpEndpoint id="defaultHttpEndpoint" httpPort="9080" httpsPort="9443"/>

    <library id="derby">
      <file name="${server.config.dir}/derby/derby.jar"/>
    </library>

    <dataSource id="DefaultDataSource">
      <jdbcDriver libraryRef="derby"/>
      <!-- Example properties referencing an in-memory Derby Embedded database -->
      <properties.derby.embedded databaseName="memory:defaultdb" createDatabase="create"/>
    </dataSource>

    <authData id="myAuth" user="dbuser" password="dbpass"/>

    <!-- Default SSL configuration enables trust for default certificates from the Java runtime -->
    <ssl id="defaultSSLConfig" trustDefaultCerts="true"/>

    <remoteFileAccess>
       <writeDir>${server.config.dir}</writeDir>
    </remoteFileAccess>

    <basicRegistry id="basic">
       <user name="admin" password="adminpwd"/>
    </basicRegistry>

    <!-- Assign 'admin' to Administrator -->
    <administrator-role>
        <user>admin</user>
    </administrator-role>

</server>

For this server.xml example, you will need to add the Derby jar to the server configuration or use your own database configuration.

Configure a Liberty server using the example server.xml file for guidance and then start the server. After the server is started, you can check the logs to find the URL to navigate to the Admin Center. In the previous example, you can navigate to the Admin Center using the https://localhost:9443/adminCenter/ URL.
Select the Server Config tool.
Select server.xml to edit.
In the Design > Server menu, navigate to the resource you want to test and click the Test button.
Choose the type of authentication your application uses:
- For applications that use container authentication, choose the Application authentication tab and select whether to use default authentication, specify an authentication alias, or choose a login module configuration.
  
  For this example, the configuration doesn’t specify default authentication on the dataSource element or configure any login modules. Therefore, you must specify an authentication alias by using the dropdown field.
- For applications that use application authentication, choose the Application authentication tab and fill in a valid user name and password for the database resource.
- If your application does not use a resource reference and the server.xml doesn’t include enableContainerAuthForDirectLookups="true" in the config element, then choose No resource reference tab and fill in a valid user name and password for the database resource.
Click the Connection Test button to run the test and display the results. The following example shows a successful connection test:

In addition to Java Database Connectivity you can also test connections to Jakarta Connectors, Jakarta Messaging and Cloudant Integration resources.

For more information about administering Liberty using a GUI, refer to the Manage Open Liberty with Admin Center documentation.

A very early preview of Jakarta Data

Jakarta Data is a new Jakarta EE specification that aims to standardize the popular Data Repository pattern across relational and NoSQL databases. As the specification is further developed and Jakarta Data providers become available, the Jakarta Data specification is expected to standardize a way to plug in your favorite providers that are currently dominant in the industry, including JNoSQL, to be used in Open Liberty.

For now, Open Liberty is using a test implementation of Jakarta Data to experiment with proposed specification features. This implementation is now available in our beta release so that developers can try out these features and provide feedback to influence the specification as it is being developed. The test implementation currently works with relational databases and operates by redirecting repository operations to the built-in Jakarta Persistence provider. It simulates the entirety of the Jakarta Data beta release, plus some additional proposed features that are being considered.

To use Jakarta Data, start by defining an entity class that corresponds to your data. With relational databases, the entity class corresponds to a database table and the entity properties (public methods and fields of the entity class) generally correspond to the columns of the table.

An entity class can use either of the following annotation schemes:

The class can be annotated with jakarta.persistence.Entity and related annotations from Jakarta Persistence.
The class can be a Java class without entity annotations, in which case the primary key is inferred from an entity property named id or ending with Id.

Next, define one or more repository interfaces for an entity, annotate those interfaces as @Repository, and inject them into components with CDI. The Jakarta Data provider supplies the implementation of the repository interface for you.

The following example shows a simple entity, a repository, and and a servlet that injects them by CDI:

public class Product { // entity
    public long id;
    public String name;
    public float price;
}

@Repository
public interface Products {
    Product findById(long productId);

    @OrderBy("price")
    List<Product> findByNameContains(String searchFor);

    @Query("UPDATE Product o SET o.price = o.price - (?2 * o.price) WHERE o.id = ?1")
    boolean discount(long productId, float discountRate);

    void save(Product p);
}

public class MyServlet extends HttpServlet {
    @Inject
    Products products;

    protected void doGet(HttpServletRequest req, HttpServletResponse resp)
            throws ServletException, IOException {
        List<Product> found = products.findByNameContains(searchFor);
        ...
    }
}

Refer to a draft of the Jakarta Data specification and the jakarta.data.repository.Repository JavaDoc for instructions on how to properly form repository methods so that the Jakarta Data provider understands them.

Optionally, a repository interface can inherit from built-in interfaces such as jakarta.data.repository.CrudRepository that define commonly used methods like findById and save for you:

@Repository
public interface Products extends CrudRepository<Product, Long> {
    @OrderBy("price")
    List<Product> findByNameContains(String searchFor);

    @Query("UPDATE Product o SET o.price = o.price - (?2 * o.price) WHERE o.id = ?1")
    boolean discount(long productId, float discountRate);
}

Jakarta Data has not yet defined a standard configuration model. For now, the Open Liberty beta reuses the existing defaultDatabaseStore configuration (which defaults to the DefaultDataSource data source) for Jakarta Data. This means the beta of Jakarta Data is currently limited to a single data source. This of course will change as the specification defines more of a configuration model. The data-1.0 Liberty beta feature makes the Jakarta Data API available, and you also need a feature for Jakarta Persistence or JDBC (or at some point in the future, Jakarta NoSQL).

Example server.xml configuration:

<server>
  <featureManager>
    <feature>data-1.0</feature>
    <feature>persistence-3.1</feature> <!-- could use jdbc-4.3 instead -->
    <feature>servlet-6.0</feature> <!-- the example includes a servlet -->
  </featureManager>

  <dataSource id="DefaultDataSource">
    <jdbcDriver libraryRef="PostgreSQL"/>
    <properties.postgresql databaseName="testdb" serverName="localhost" portNumber="5432"/>
    <containerAuthData user="dbuser1" password="dbpwd1"/>
  </dataSource>

  <library id="PostgreSQL">
    <file name="${shared.resource.dir}/jdbc/postgresql.jar"/>
  </library>

  <!-- optional because the following are all defaulted: -->
  <databaseStore id="defaultDatabaseStore" createTables="true" dropTables="false"
          tablePrefix="WLP" dataSourceRef="DefaultDataSource"/>
</server>

You can find the initial 1.0.0-b1 beta release of Jakarta Data on Maven, which corresponds to the Open Liberty 23.0.0.2-beta.

<dependency>
  <groupId>jakarta.data</groupId>
  <artifactId>jakarta-data-api</artifactId>
  <version>1.0.0-b1</version>
</dependency>

Experimental function in the beta of Jakarta Data

This beta provides some additional function that is under consideration for Jakarta Data, but not in the Jakarta Data 1.0.0-b1 beta.

When a global transaction is active on the thread on which a repository operation executes, the repository operation enlists as part of the transaction, if the data source that backs the repository is capable of enlistment. Transaction enlistment is default for relational databases, but you can switch it off by setting the transactional data source configuration attribute to false in your server configuration.

When the the concurrent-3.0 feature is enabled, you can use the @Asynchronous annotation from Jakarta Concurrency on repository methods to enable them to run asynchronously.

@Repository
public interface Products extends CrudRepository<Product, Long> {
    @Asynchronous
    @OrderBy("price")
    CompletableFuture<List<Product>> findByNameContains(String searchFor);

    @Asynchronous
    @Query("UPDATE Product o SET o.price = o.price - (?2 * o.price) WHERE o.id = ?1")
    CompletionStage<Boolean> discount(long productId, float discountRate);
}

You can also try out the ability to define queries annotatively:

@Repository
public interface Products extends CrudRepository<Product, Long> {
    @Filter(by = "name", op = Compare.Contains)
    @Filter(by = "price", op = Compare.LessThanEqual)
    @OrderBy("price")
    List<Product> searchFor(String nameMatch, float maxPrice);

    @Filter(by = "id")
    @Update(attr = "price", op = Operation.Multiply)
    boolean adjustPrice(long productId, float ratio);

    @Delete
    @Filter(by = "name", ignoreCase = true)
    void discontinue(String productName);
}

Jakarta EE 10 and MicroProfile 6

This beta release also includes Jakarta EE Platform 10 and MicroProfile 6, which were first made available in the 22.0.0.13-beta. To find out more, reference the 22.0.0.13-beta blog post.

Try it now

To try out these features, update your build tools to pull the Open Liberty All Beta Features package instead of the main release. The beta works with Java SE 19, Java SE 17, Java SE 11, and Java SE 8.

If you’re using Maven, you can install the All Beta Features package using the following pom.xml configuration:

<plugin>
    <groupId>io.openliberty.tools</groupId>
    <artifactId>liberty-maven-plugin</artifactId>
    <version>RELEASE</version>
    <configuration>
        <runtimeArtifact>
          <groupId>io.openliberty.beta</groupId>
          <artifactId>openliberty-runtime</artifactId>
          <version>23.0.0.2-beta</version>
          <type>zip</type>
        </runtimeArtifact>
    </configuration>
</plugin>

<dependency>
    <groupId>org.eclipse.microprofile</groupId>
    <artifactId>microprofile</artifactId>
    <version>6.0-RC3</version>
    <type>pom</type>
    <scope>provided</scope>
</dependency>
<dependency>
    <groupId>jakarta.platform</groupId>
    <artifactId>jakarta.jakartaee-api</artifactId>
    <version>10.0.0</version>
    <scope>provided</scope>
</dependency>

Or for Gradle:

dependencies {
    libertyRuntime group: 'io.openliberty.beta', name: 'openliberty-runtime', version: '[23.0.0.2-beta,)'
}

Or take a look at our Downloads page.

For more information on using a beta release, refer to the Installing Open Liberty beta releases documentation.

We welcome your feedback

Let us know what you think on our mailing list. If you hit a problem, post a question on StackOverflow. If you hit a bug, please raise an issue.

Jakarta EE, MicroProfile, and Liberty configuration editing support in IntelliJ IDEA with Liberty Tools (early release)

Tue, 14 Feb 2023 00:00:00 +0000

With the latest early release of Liberty Tools for IntelliJ IDEA, you can iterate fast with Liberty dev mode, code with assistance for MicroProfile and Jakarta EE APIs, and easily edit Liberty configuration files, all from within the editor.

Try it out today with IntelliJ IDEA 2022.2+, installable via the Jetbrains marketplace.

Check out the YouTube video to see all the Liberty Tools for IntelliJ IDEA features.

What’s New

Type-ahead completion for Jakarta EE, MicroProfile, and Liberty configuration files

In this early release, we add all new type-ahead completion assistance for your Liberty configuration files and Jakarta EE and MicroProfile APIs.

Liberty configuration assistance provides code completion in Liberty server.xml, server.env, and bootstrap.properties files. For example, the completion in the following example offers possible Liberty features you can configure in your server.xml file’s featureManager block.

Editing assistance provides code completion in configuration and application files for Jakarta EE and MicroProfile APIs. For example, the rest_get code completion in the following example inserts a code snippet for a RESTful Web Services GET method.

If you prefer to work entirely through keyboard shortcuts, all Liberty actions can now be run through the IntelliJ Go to Action menu. You can access the menu either by pressing Shift twice, then selecting the Actions tab, or by pressing Ctrl + Shift + A or Cmd + Shift + A.

Attach a debugger at startup

When you select the Liberty Start… action from the Liberty tool window or IntelliJ Go To Action menu, you can configure a new run configuration with Maven or Gradle parameters to pass to the mvn liberty:dev or gradle libertyDev commands. This configuration integrates into the IntelliJ IDEA run/debug configuration view.

When you select the newly created Liberty run configuration and then select the IntelliJ Debug icon, your Liberty server will start and attach a JVM debugger all in one step. The Debug action will determine an available port on your system and pass that port to dev mode. As soon as dev mode starts, you can start debugging your application through the built-in IntelliJ IDEA debug view.

For a full list of newly added features and bug fixes, check out the 0.0.8 release notes.

Stay tuned for more…

The team is actively developing new features, including hover for more information, diagnostics, and quick-fixes to add even more editing assistance directly in-editor.

Do you have ideas for new features? Open an issue on GitHub.

Prefer another IDE? Check out Liberty Tools for Eclipse IDE or Liberty Tools for Visual Studio Code.

Jakarta EE 10 Platform and MicroProfile 6 in Open Liberty 23.0.0.1-beta

Tue, 03 Jan 2023 00:00:00 +0000

Open Liberty 23.0.0.1-beta offers the same set of beta content as the previous 22.0.0.13-beta release: Jakarta EE Platform 10 and MicroProfile 6. To find out more, reference the 22.0.0.13-beta blog post. This beta release also includes a way to configure the maximum age for FFDC files and various bug fixes, which you can learn more about in the 22.0.0.13 release blog post.

Try it now

If you’re using Maven, you can install the All Beta Features package using:

<plugin>
    <groupId>io.openliberty.tools</groupId>
    <artifactId>liberty-maven-plugin</artifactId>
    <version>RELEASE</version>
    <configuration>
        <runtimeArtifact>
          <groupId>io.openliberty.beta</groupId>
          <artifactId>openliberty-runtime</artifactId>
          <version>23.0.0.1-beta</version>
          <type>zip</type>
        </runtimeArtifact>
    </configuration>
</plugin>

<dependency>
    <groupId>org.eclipse.microprofile</groupId>
    <artifactId>microprofile</artifactId>
    <version>6.0-RC3</version>
    <type>pom</type>
    <scope>provided</scope>
</dependency>
<dependency>
    <groupId>jakarta.platform</groupId>
    <artifactId>jakarta.jakartaee-api</artifactId>
    <version>10.0.0</version>
    <scope>provided</scope>
</dependency>

Or for Gradle:

dependencies {
    libertyRuntime group: 'io.openliberty.beta', name: 'openliberty-runtime', version: '[23.0.0.1-beta,)'
}

Or take a look at our Downloads page.

For more information on using a beta release, refer to the Installing Open Liberty beta releases documentation.

We welcome your feedback

Let us know what you think on our mailing list. If you hit a problem, post a question on StackOverflow. If you hit a bug, please raise an issue.

Fast iterative cloud-native Java application development with Liberty Tools

Tue, 20 Dec 2022 00:00:00 +0000

Developers need tools for cloud-native Java application development that are both intuitive and delightful. Enter Liberty Tools: the next-generation tools for developers to build applications with Liberty within the Eclipse IDE, Visual Studio Code, and IntelliJ IDEA integrated development environments (IDE).

Liberty Tools can simplify your iterative coding cycle by taking away mundane manual tasks and providing coding support for the APIs you use. They also give you flexibility in your choice of IDE.

Liberty Tools bring together a range of capabilities:

Iterate fast with Liberty dev mode integrated within your IDE. With dev mode, we do the heavy lifting for you: code changes are automatically detected, recompiled, and deployed whenever you save a new change. You can test and debug right away.
Write code confidently using MicroProfile and Jakarta EE APIs with assistance such as validations, quick fixes, completions.
Edit Liberty configuration files easily with assistance.
Use Liberty build plug-ins for Maven and Gradle to build your applications.

Today, we are delighted to share that an early release refresh of the Liberty Tools is available. This release provides a core set of capabilities for building cloud-native Java applications with Liberty, including support for Jakarta EE 9.x Web Profile and MicroProfile 3 & 4 APIs. Learn more about Liberty Tools and try them out:

Do let us know what you think. Your feedback is important as we round out the capabilities and graduate Liberty Tools from early release status!

Open issues for Liberty Tools for Eclipse IDE
Open issues for Liberty Tools for Visual Studio Code
Open issues for Liberty Tools for IntelliJ IDEA

We will dive into the tools further in future blog posts. Stay tuned!

Proposal to relicense Open Liberty to EPLv2

Wed, 07 Dec 2022 00:00:00 +0000

To continue Open Liberty’s contributions as a compatible implementation for the MicroProfile and Jakarta EE specifications, we are strongly considering relicensing Open Liberty under the EPLv2 public license. We hope to make this change early in 2023 and are seeking feedback from the community on this decision now. We want to give the community an opportunity to provide feedback on this process. Earlier this week, I created a GitHub issue to track making this change and we invite you to provide feedback in comments in that issue. The intent of this blog post is to both solicit feedback and to explain the reason we are considering this change.

Open Liberty and the EPL

When we created Open Liberty in 2017, we looked at a number of open source licenses that existed at the time and chose to use the Eclipse Public License (EPL). Shortly before we released Open Liberty, the Eclipse Foundation released the Eclipse Public License v2 (EPLv2). At the time, we discussed changing the license, but decided against it because it would delay releasing Open Liberty without much benefit.

Open Liberty as a compatible implementation in the spec finalization process

Moving on 5 years, many things have changed, including the move of the MicroProfile and Java EE (now Jakarta EE) standards to Eclipse under the Eclipse Foundation Specification Process (EFSP). The EFSP says that to release a specification (such as a MicroProfile or Jakarta EE specification) there must be an implementation of that specification that is licensed under either the EPLv2, Eclipse Distribution License, or Apache License 2. Open Liberty has been used as a compatible implementation for finalizing MicroProfile and Jakarta EE specifications but Open Liberty is distributed under none of these licenses.

This was an oversight by all involved, but it means we have a choice: we either relicense Open Liberty to a license that the EFSP allows for spec finalization, or we don’t use Open Liberty to finalize specifications. Providing compatible implementations for use in spec finalization is an important part of defining a specification and I have been proud that Open Liberty has been able to take this role in the past and I would like to continue to do this into the future.

Implications of changing from EPLv1 to EPLv2

I’m not an expert on licenses, but my understanding is that the changes between v1 and v2 clarify the language of the original license rather than granting any additional rights over the source code. There are updates for secondary licenses, but Open Liberty is not using those capabilities of the license so it is not relevant to Open Liberty. The EPLv1 license has language to simplify relicensing to new versions of the license.

We welcome feedback on this proposed relicensing

The result is that we want to relicense Open Liberty from EPLv1 to EPLv2 early in 2023. Although we believe that relicensing from EPLv1 to EPLv2 is uncontroversial and relatively straightforward, we want to solicit feedback from the community ahead of making any change. If you have feedback on this change, please let us know in this GitHub issue before the end of 2022. Some of the changes for relicensing are less disruptive when the codebase is subject to less change, which is the case over the year-end break, so we hope to make a final decision early in the new year.

Jakarta EE 10 Platform and MicroProfile 6 in Open Liberty 22.0.0.13-beta

Tue, 06 Dec 2022 00:00:00 +0000

With Open Liberty 22.0.0.13-beta we’re excited to announce many new features and functions, beginning with Jakarta EE Web Profile 10.0 and Jakarta EE Platform 10.0! To make that possible, this release also includes the last remaining Jakarta EE 10 features that had not previously been part of a beta: Jakarta Authentication 3.0, Jakarta Authorization 2.1, Jakarta Security 3.0, and Jakarta Faces 4.0.

Similar to Jakarta EE 10 features, we’ve also been releasing various MicroProfile 6 features in the recent beta releases, and the 22.0.0.13-beta marks the first release that includes all of MicroProfile 6! Also provided in this beta release is the ability to automatically purge FFDC log files after they reach a configured age.

The Open Liberty 22.0.0.13-beta includes the following beta features (along with all GA features):

Jakarta EE 10 Platform and Web Profile
MicroProfile 6.0
Configurable maximum FFDC age

Jakarta EE 10 Platform and Web Profile

In the Open Liberty 22.0.0.9-beta, we made available Jakarta EE 10 Core Profile and ever since we’ve been hard at work releasing more Jakarta EE 10 features with each subsequent beta. We’re proud to announce that the 22.0.0.13-beta is the culmination of that effort and makes available Jakarta EE 10.0 Application Client, Jakarta EE Web Profile 10.0, and Jakarta EE Platform 10.0.

Liberty provides convenience features for running all of the component specifications that are contained in the Jakarta EE Web Profile and Jakarta EE Platform. The webProfile-10.0 and jakartaee-10.0 Liberty features provide the Jakarta EE Web Profile and Jakarta EE Platform version 10 Liberty features respectively. For Jakarta EE 10 features in the application client, use the jakartaeeClient-10.0 Liberty feature.

Using these convenience features enables developers to rapidly develop applications using all of the APIs contained in the Web Profile and Platform specifications. Unlike the webProfile-9.1 Liberty feature, the webProfile-10 Liberty feature does not enable the XML Binding feature, because XML Binding is not a Web Profile component specification. If your application relies on XML Binding APIs, you must explicitly enable the xmlBinding-4.0 Liberty feature when using the webProfile-10.0 Liberty feature.

To enable the Jakarta EE 10 beta features in your application’s server.xml:

  <featureManager>
    <feature>jakartaee-10.0</feature>
  </featureManager>

Or you can add the Web Profile convenience feature to enable all of the Jakarta EE 10 Web Profile beta features at once:

  <featureManager>
    <feature>webProfile-10.0</feature>
  </featureManager>

To run Jakarta EE 10 features on the Application Client Container in your application’s client.xml:

 <featureManager>
       <feature>jakartaeeClient-10.0</feature>
 </featureManager>

For more information see the Jakarta EE Platform 10 Specification and the Jakarta EE Web Profile 10 Specification.

Application Authentication 3.0 (Jakarta Authentication 3.0)

Jakarta Authentication defines a general low-level SPI for authentication mechanisms, which are controllers that interact with a caller and a container’s environment to obtain and validate the caller’s credentials and pass an authenticated identity (such as name and groups) to the container.

Multiple enhancements are made available in Jakarta Authentication 3.0, including methods to add and remove a single server auth module, and the addition of default methods to ServerAuth and ClientAuth modules.

You can enable the Jakarta Authentication 3.0 feature by enabling the appAuthentication-3.0 feature in the server.xml file:

    <featureManager>
        <feature>appAuthentication-3.0</feature>
    </featureManager>

For more information, see the Jakarta Authentication 3.0 specification.

Application Authorization 2.1 (Jakarta Authorization 2.1)

Jakarta Authorization defines a low-level SPI for authorization modules, which are repositories of permissions facilitating subject based security by determining whether a given subject has a given permission, and algorithms to transform security constraints for specific containers (such as Jakarta Servlet or Jakarta Enterprise Beans) into these permissions.

The Jakarta Authorization 2.1 specification provides enhancements to the Jakarta Authorization 2.0 specification by the addition of new methods to read permissions. One such addition is the ability to get the PolicyConfiguration, which is used for authorization. Prior to Jakarta Authorization 2.1, the spec did not have the flexibility to read permissions from the PolicyConfiguration and required complex wrapper code to get the PolicyConfiguration.

You can enable the Jakarta Authorization 2.1 feature by using the appAuthorization-2.1 feature in the server.xml file:

    <featureManager>
        <feature>appAuthorization-2.1</feature>
    </featureManager>

For more information see the Jakarta Authorization 2.1 specification.

Application Security 5.0 (Jakarta Security 3.0)

Application Security 5.0 enables support for securing the server runtime environment and applications using Jakarta Security 3.0. The Jakarta Security 3.0 specification allows using built-in authentication mechanisms and identity stores as well as providing your own custom implementations for authenticating users to protected resources. The specification introduces a new built-in authentication mechanism based on the Authorization Code Flow of the OpenID Connect Core 1.0 specification.

Jakarta Security 3.0 allows using the new @OpenIdAuthenticationMechanismDefinition annotation to configure a built-in OpenID Connect authentication mechanism to function as an OpenID Connect client, or Relying Party (RP), so that you can use an OpenID Connect Provider (OP) as a single sign-on identity provider. It also introduces the OpenIdContext bean and various APIs for handling the access token, identity token, and refresh token.

You can use the @OpenIdAuthenticationMechanismDefinition annotation in a Web or JAX-RS application to enable an OpenID Connect client for that application. The following example shows a servlet with a minimal @OpenIdAuthenticationMechanismDefinition annotation when the OP is a Liberty OP:

@WebServlet("/OidcAnnotatedServlet")
@OpenIdAuthenticationMechanismDefinition(
                providerURI = "https://localhost:8920/oidc/endpoint/OP",
                clientId = "clientId",
                clientSecret = "clientSecret",
                redirectURI = "https://localhost:8940/MyApp/Callback",
                claimsDefinition = @ClaimsDefinition(callerNameClaim = "sub", callerGroupsClaim = "groupIds"))
@DeclareRoles("all")
@ServletSecurity(@HttpConstraint(rolesAllowed = "all"))
public class OidcAnnotatedServlet extends HttpServlet {
…
}

You can enable the Application Security 5.0 (Jakarta Security 3.0) feature by using the appSecurity-5.0 feature in the server.xml file:

    <featureManager>
        <feature>appSecurity-5.0</feature>
    </featureManager>

For more information about the @OpenIdAuthenticationMechanismDefinition annotation and its attributes, refer to the 2.4.4. OpenID Connect Annotation section of the Jakarta Security 3.0 specification. Please refer to Jakarta Security Module for the documentation of the Jakarta Security 3.0 APIs.

Jakarta Faces 4.0

Jakarta Faces is a Model-View-Controller (MVC) framework for building web applications. It offers many convenient features, such as state management and input validation.

Numerous changes have occurred since the last Jakarta Faces release. Notably, Pages (formerly JSP) support has been removed. Managed Beans support has also been removed, and developers should use CDI beans from this version forward. The namespaces also have been updated from http://xmlns.jcp.org/jsf/* to jakarta.faces.*. Otherwise, new attributes have been added to existing tags: multiple and accept for h:inputFile and onerror for f:websocket. Developers can now create facelets programmatically rather than building them via XML. Extensionless mapping is implemented, so URLs no longer need to include /faces or .xhtml mappings. Two new tags have been added to create a nested collections (i.e., optgroup containing option elements): f:selectItemGroups and f:selectItemGroup. These are just some significant changes, but there are many more.

The faces-4.0 feature uses MyFaces, but if you want to use an alternative Faces implementation, such as Mojarra 4.0, you can use the facesContainer-4.0 feature instead. The Faces API and implementation jars just need to be included in the application WEB-INF/lib folder.

You can enable the Jakarta Faces 4.0 feature by using the faces-4.0 feature in the server.xml file:

    <featureManager>
        <feature>faces-4.0</feature>
    </featureManager>

To enable the Jakarta Faces 4.0 feature, add faces-4.0 to the server.xml file:

    <featureManager>
        <feature>facesContainer-4.0</feature>
    </featureManager>

You can find more information regarding the many changes in Faces 4.0 in the What’s new in Faces 4.0? article. The Javadoc, specification documentation, and other information can be found on the Faces 4.0 page.

MicroProfile 6.0

MicroProfile 6.0 enables applications to use MicroProfile APIs together with Jakarta EE 10 Core Profile. The complete list of MicroProfile 6.0 specifications includes:

The following specifications in MicroProfile 6.0 release are either new or have some major or minor update when compared to MicroProfile 5.0:

MicroProfile Telemetry 1.0 (new spec; find out more in the 22.0.0.10-beta post)
MicroProfile Metrics 5.0 (major update; find out more in the 22.0.0.12-beta post)
MicroProfile OpenAPI 3.1 (minor update; find out more in the 22.0.0.9-beta post)
MicroProfile JWT 2.1 (minor update; find out more in the 22.0.0.12-beta post)

MicroProfile 6.0 has the following backward incompatible changes compared to MicroProfile 5.0:

Incompatible changes from MicroProfile Metrics
MicroProfile OpenTracing replaced by MicroProfile Telemetry
Includes Jakarta EE 10 Core Profile instead of the five specifications (CDI, Jakarta Restful Web Services, JSON-B, JSON-P and Annotations) in Jakarta EE 9.1

It’s also worth noting that MicroProfile Metrics 5.0 has incompatible changes compared to MicroProfile Metrics 4.0.

You can enable the MicroProfile 6 feature by using the microProfile-6.0 feature in the server.xml file:

<featureManager>
    <feature>microProfile-6.0</feature>
</featureManager>

To find out more, take a look at the MicroProfile 6.0 Release.

Configurable maximum FFDC age

Open Liberty provides First Failure Data Capture(FFDC) capability which instantly collects information about events and conditions that might lead up to a failure. In certain scenarios, the number of files in the FFDC directory can grow to a very large amount. Currently, Open Liberty automatically purges FFDC files in excess of 500 and this value is not configurable. This beta release introduces new functionality which automatically purges FFDC log files after they reach a configured age. This is done through a new configuration attribute, maxFfdcAge.

maxFfdcAge is the maximum desired age before an FFDC file is deleted. At midnight everyday, any FFDC file that has reached the maximum configured age will be deleted. Specify a positive integer followed by a unit of time, which can be days (d), hours (h), or minutes (m). For example, specify 2 days as 2d. You can include multiple values in a single entry. For example, 2d6h is equivalent to 2 days and 6 hours.

Example server.xml configuration:

<server>
    <logging maxFfdcAge="2d"/>
</server>

Try it now

To try out these features, just update your build tools to pull the Open Liberty All Beta Features package instead of the main release. The beta works with Java SE 19, Java SE 17, Java SE 11, and Java SE 8.

If you’re using Maven, you can install the All Beta Features package using:

<plugin>
    <groupId>io.openliberty.tools</groupId>
    <artifactId>liberty-maven-plugin</artifactId>
    <version>3.3.4</version>
    <configuration>
        <runtimeArtifact>
          <groupId>io.openliberty.beta</groupId>
          <artifactId>openliberty-runtime</artifactId>
          <version>22.0.0.13-beta</version>
          <type>zip</type>
        </runtimeArtifact>
    </configuration>
</plugin>

<dependency>
    <groupId>org.eclipse.microprofile</groupId>
    <artifactId>microprofile</artifactId>
    <version>6.0-RC3</version>
    <type>pom</type>
    <scope>provided</scope>
</dependency>
<dependency>
    <groupId>jakarta.platform</groupId>
    <artifactId>jakarta.jakartaee-api</artifactId>
    <version>10.0.0</version>
    <scope>provided</scope>
</dependency>

Or for Gradle:

dependencies {
    libertyRuntime group: 'io.openliberty.beta', name: 'openliberty-runtime', version: '[22.0.0.13-beta,)'
}

Or take a look at our Downloads page.

We welcome your feedback

Let us know what you think on our mailing list. If you hit a problem, post a question on StackOverflow. If you hit a bug, please raise an issue.

Jakarta EE with Liberty Tools for Eclipse IDE

Fri, 04 Nov 2022 00:00:00 +0000

Since introducing Liberty Tools for Eclipse IDE in August, we’ve continued to add new features with each new early release. Currently at version 0.4, Liberty Tools now supports developing Jakarta EE applications and editing Liberty’s bootstrap.properties and server.env files.

Let’s take a closer look.

Develop Jakarta EE applications

Integration with the Eclipse Language Server for Jakarta EE (Eclipse LSP4Jakarta) helps you intuitively develop with Jakarta EE. Features such as autocompletion, quick-fixes and type-ahead seamlessly integrate into your day-to-day development, making it easy to find the right methods and annotations for your application.

Additionally, pre-configured annotations, methods and even full classes can be added to your application automatically with code snippets. These snippets get you up and running fast without having to worry about syntax, annotations or referencing example code.

Edit Liberty server config

Liberty Tools now supports config assist and auto-completion when you edit bootstrap.properties and server.env files. You can easily look up the properties and values you need without leaving your IDE.

Try it out!

Like what you see? Check out Liberty Tools for Eclipse to try the early release out for yourself, give feedback, and see what’s coming next as we prepare for v1.0.

The Jakarta community is always looking for contributors. Check out the Language Server for Jakarta EE to contribute to the project!

More Jakarta EE 10 and MicroProfile 6 features make their debut in Open Liberty 22.0.0.12-beta!

Thu, 27 Oct 2022 00:00:00 +0000

As we progress towards full Jakarta EE 10 compliance, the 22.0.0.12-beta release includes six new Jakarta EE 10 specifications, alongside the ones that were included in previous beta releases.

Jakarta Batch 2.1 provides improved CDI integration while Jakarta XML Web Services 4.0 now incorporates Jakarta Web Services Metadata. Jakarta Pages 3.1 provides developers an option to raise Exceptions for undefined Expression Language Identifiers, while Jakarta Tags 3.0 includes Tag URI renaming when referencing tag libraries. Jakarta Messaging 3.1 makes connection factory and destination definition annotations repeatable, while Jakarta WebSocket 2.1 allows for the registration of endpoints outside of the deployment phase.

But this beta includes more than just Jakarta EE 10 features; two new MicroProfile 6.0 features are also included! MicroProfile JSON Web Token 2.1 includes simplified JWT validation and MicroProfile Metrics 5.0 provides user-defined metric registry scopes.

The Open Liberty 22.0.0.12-beta includes the following beta features (along with all GA features):

Jakarta EE 10:
MicroProfile 6.0:
- Simplified JWT Validation (MicroProfile JSON Web Token 2.1)
- User-defined metric registry scopes (MicroProfile Metrics 5.0)

For a full list of new and updated MicroProfile 6.0 features in Open Liberty, see the 22.0.0.13-beta post.

Option to raise Exceptions for undefined Expression Language Identifiers (Jakarta Pages 3.1 and Jakarta Tags 3.0)

Jakarta Pages is a template engine that allows developers to mix various content, such as HTML, XML, and Java code, and translate it into a Jakarta Servlet. Jakarta Standard Tag Library allows for tags to encapsulate common functionality used in many web applications. The Open Liberty pages-3.1 feature is an implementation of both the Jakarta Pages 3.1 and Jakarta Standard Tag Library 3.0 specifications. It includes new features, behavior clarifications, and deprecations from the previous 3.0 version.

The new pages-3.1 feature allows developers to identify undefined Expression Language variables by using a new option, which raises a PropertyNotFoundException and can be set in one of two ways. The errorOnELNotFound attribute is set as a page or tag directive. The <error-on-el-not-found> element is set in the web.xml file.

Previously, imported packages and classes were only available to the scripting environment (i.e. scriptlet tags). However, with version 3.1, they are also available in the Expression Language environment within the page. Default imports (such as jakarta.servlet, jakarta.servlet.jsp, jakarta.servlet.jsp.http) are consistent between both environments. Related changes included internal refactoring of the ScopedAttributeELResolver to create ImportELResolver and the addition of the NotFoundELResolver, which always resolves the requested value and returns null.

Other significant changes include the deprecation of the isThreadSafe directive, the jsp:plugin (including the related jsp:params and jsp:fallback) actions, and any methods which overrode ELResolver.getFeatureDescriptors().

As for Jakarta Tags 3.0, the largest change includes the Tag URI renaming when referencing tag libraries. For example, jakarta.tags.core now replaces the http://xmlns.jcp.org/jsp/jstl/core URI when importing the core tag library. However, the implementation kept older URIs for backwards compatibility. The remaining changes related to general clean up of the documentation.

To enable the new Jakarta Server Pages 3.1 and Jakarta Standard Tag Library 3.0 features, add the pages-3.1 feature to your server.xml:

<featureManager>
   <feature>pages-3.1</feature>
</featureManager>

For more information about Jakarta Server Pages and Jakarta Standard Tag Library, refer to the following links:

Register endpoints outside of the deployment phase (Jakarta WebSocket 2.1)

Jakarta WebSocket allows communication via the WebSocket protocol, allowing for full-duplex communication between endpoints. This means that a single, persisted connection is made across the endpoints, allowing both the server and client to continuously and simultaneously push information to each other.

Jakarta WebSocket 2.1 is the latest version of the specification and provides several new features and behavior clarifications aimed at improving WebSocket development. Firstly, when setting up dependencies, developers are likely to notice the API JARs are refactored into client and server JARs. However, both APIs are available as part of the websocket-2.1 feature.

HTTP connection upgrades to the WebSocket protocol can now occur via the ServerContainer.upgradeHttpToWebSocket() method rather than IBM’s specific WsWsocServerContainer.doUpgrade() method.

Another change regards the Session#getUserProperties() method. The returned map is now a copy per endpoint instance, per WebSocket session. Additionally, the server session’s user properties are initially populated by the ServerEndpointConfig.getUserProperties() method, so endpoints can retrieve properties set in the ServerEndpointConfig.Configurator.modifyHandshake() method. This is similar to the client session as the user properties are a shallow copy from the EndpointConfig.getUserProperties() method.

Lastly, there were many clarifications in the spec, such as requiring the Session.getRequestURI() method to return the whole URI. These clarifications can be viewed on the Jakarta WebSocket 2.1 page.

You can enable the Jakarta WebSocket 2.1 feature by using the websocket-2.1 feature in the server.xml file,

<featureManager>
   <feature>websocket-2.1</feature>
</featureManager>

For more information about Jakarta WebSocket, refer to the following links:

Improved CDI integration (Jakarta Batch 2.1)

The updates in Jakarta Batch 2.1 primarily focus on improved integration with Context Dependency Injection (CDI). Discovery of Batch artifacts is now standardized via CDI, whereas before it was not fully defined in the specification.

Previously, the default JobOperator was only made available from a static factory method, BatchRuntime.getJobOperator(). With Jakarta Batch 2.1, the default JobOperator is provided as a CDI bean unless one is defined by the user application, if an injectable field is available as defined by:

@Inject
JobOperator jobOperator;

Previously, the @BatchProperty annotation allowed for injection of String-type values only, but is now expanded to most other primitive types. For example:

@Inject @BatchProperty(name="p1") String p1;

This property can have other types in Jakarta Batch 2.1, including Boolean, Integer, Long, Float, and Double. For example:

@Inject @BatchProperty(name="p1") Integer p1;

The batch-2.1 feature is the implementation of Jakarta Batch 2.1 for use with other Jakarta EE 10 features. It can be activated by including the batch-2.1 feature directly, or by including batchManagement-1.0 along with another Jakarta EE 10 feature. For example:

<featureManager>
   <feature>batchManagement-1.0</feature>
   <feature>servlet-6.0</feature>
</featureManager>

For more information regarding Jakarta Batch 2.1, refer to the following links:

Connection factory and destination definition annotations are now repeatable (Jakarta Messaging 3.1)

Jakarta Messaging is a set of APIs to standardize message communication between applications, defining how the messages are created, sent, received, and interpreted. Jakarta Messaging 3.1 provides minor changes and enhancements to the specification. Two noteworthy updates are the requirement for Java 11 and making the @JMSConnectionFactoryDefinition and @JMSDestinationDefinition annotations repeatable.

To enable the new Jakarta Messaging 3.1 feature, add the messaging-3.1 feature to your server.xml:

<featureManager>
   <feature>messaging-3.1</feature>
</featureManager>

For more information about Jakarta Messaging, refer to the following links:

Jakarta Web Services Metadata incorporated into XML Web Services 4.0

Jakarta XML Web Services 4.0 is a set of APIs that allows applications to deploy SOAP-based web services on the Jakarta EE 10 platform. This set of APIs includes both the XML Web Services 4.0 specification, which now incorporates the Jakarta Web Services Metadata specification, as well as the Jakarta SOAP with Attachments 3.0 specification.

Although the changes introduced in XML Web Services 4.0 are relatively minor, they do include the requirement for Java SE 11, as well as incorporating the Jakarta Web Services Metadata specification into XML Web Services 4.0.

To enable the new Jakarta XML Web Services 4.0 feature, add the xmlWS-4.0 feature to your server.xml:

<featureManager>
   <feature>xmlWS-4.0</feature>
</featureManager>

For more information about Jakarta XML Web Services, refer to the following links:

Simplified JWT Validation (MicroProfile JSON Web Token 2.1)

The MicroProfile JSON Web Token 2.1 specification allows the use of a JWT to authenticate and authorize requests to a service. The specification simplifies managing the validation of the JWT by introducing three new MicroProfile Config properties, along with corresponding mpJwt attributes.

mp.jwt.verify.token.age

The mp.jwt.verify.token.age property allows you to specify the number of seconds since the JWT token was issued. The iat (issued at) claim must be present in the JWT and the configured number of seconds since iat must not have elapsed. If it has elapsed, then the request is rejected with an Unauthorized (401) response.

The new tokenAge attribute of the mpJwt element overrides the mp.jwt.verify.token.age property.

mp.jwt.verify.clock.skew

The mp.jwt.verify.clock.skew property allows you to specify the clock skew in seconds used during the token expiry and age verification. The default value is 0 seconds. In order to use this new property, set a negative value for the clockSkew attribute of the mpJwt element since the mpJwt element already has a default value of 5 minutes for the clockSkew attribute. For example:

<mpJwt id="myMpJwt" clockSkew="-1"/>

If clockSkew is not specified or it has a value greater than 0, then it will override the mp.jwt.verify.clock.skew property.

mp.jwt.decrypt.key.algorithm

The mp.jwt.decrypt.key.algorithm property allows you to specify the Key Management Algorithm for decrypting the Content Encryption Key (CEK) when receiving JWE tokens. There is no default value. The alg header parameter must be present in the JWE and must be the same value as the mp.jwt.decrypt.key.algorithm property. If it is not the same value, then the request is rejected with an Unauthorized (401) response. For example:

mp.jwt.decrypt.key.algorithm=RSA-OAEP

The new keyManagementKeyAlgorithm attribute of the mpJwt element overrides the mp.jwt.decrypt.key.algorithm property.

You can enable the MicroProfile JSON Web Token 2.1 feature by using the mpJwt-2.1 feature in the server.xml file:

<featureManager>
   <feature>mpJwt-2.1</feature>
</featureManager>

For more information regarding MicroProfile JSON Web Token, refer to the following links:

User-defined metric registry scopes (MicroProfile Metrics 5.0)

The MicroProfile Metrics 5.0 feature is the implementation of the Eclipse MicroProfile Metrics 5.0 release and is compatible to run only with other Jakarta EE 10 features. This latest version of MicroProfile Metrics includes both new functionality and significant changes to the functionality in MicroProfile Metrics 4.0 (i.e. the Open Liberty mpMetrics-4.0 feature).

Before we cover the new, lets first quickly go over the changes to existing functionality. Most notable is the removal of the Meter, ConcurrentGauge and SimpleTimer metrics. A consequence of this change is that the REST.request metric, which was previously backed by a SimpleTimer metric, is now a Timer metric. For the publishing of metrics, only the Prometheus format is now available, and the JSON formatted output has been removed. Additionally, the metrics endpoint for a specific metric registry scope and metric is no longer accessed through a tree hierarchy, but rather through query params. For example, /metrics/base/jvm.uptime is accessed through /metrics?scope=base&metric=jvm.uptime. The /metrics?scope=base endpoint by itself retrieves the metrics for the base metric registry.

New in this release is the introduction of user-defined custom scopes. Prior to this release, there was only the base, vendor and application scopes and only the application scope could be used to register metrics. Now, metrics can be registered to a user-defined metric registry scope in one of the following two ways.

Scope attribute in a the metric annotations

@Counted(name = "myCounter", scope ="customScope")
public void foo(){
   ...
}

Inject a metric registry with a custom scope using the new `@RegistryScope` annotation

@Inject
@RegistryScope(scope="customScope")
MetricRegistry metricRegistry;

The @RegistryType injection qualifier is still available, but is now deprecated.

Furthermore, the mp.metrics.smallrye.timer.precision and mp.metrics.smallrye.histogram.precision MicroProfile Config properties are introduced in this release. These properties specify the percentile accuracy used by the Timer and Histogram metrics. The valid values are 1-5. The default value is 3. The higher the number, the greater the precision, but the greater the memory usage.

These only the most notable and impactful changes. There are further changes to the API that are not covered in this blog. For a comprehensive list of changes to the MicroProfile Metrics technology, go to the Eclipse MicroProfile Metrics project page.

You can enable the MicroProfile Metrics 5.0 feature by using the mpMetrics-5.0 feature in the server.xml file,

<featureManager>
   <feature>mpMetrics-5.0</feature>
</featureManager>

For more information about MicroProfile Metrics, refer to the following links:

Try it now

If you’re using Maven, here are the coordinates:

<dependency>
  <groupId>io.openliberty.beta</groupId>
  <artifactId>openliberty-runtime</artifactId>
  <version>22.0.0.12-beta</version>
  <type>pom</type>
</dependency>

Or for Gradle:

dependencies {
    libertyRuntime group: 'io.openliberty.beta', name: 'openliberty-runtime', version: '[22.0.0.12-beta,)'
}

Or take a look at our Downloads page.

We welcome your feedback

Let us know what you think on our mailing list. If you hit a problem, post a question on StackOverflow. If you hit a bug, please raise an issue.

Liberty InstantOn startup for cloud native Java applications

Thu, 29 Sep 2022 00:00:00 +0000

This article was published when Liberty InstantOn was still beta. Liberty InstantOn moved out of beta as of the Liberty 23.0.0.6 release. For the latest information about Liberty InstantOn, see Faster startup for containerized applications with Open Liberty InstantOn in the Open Liberty docs.

Do you want cloud-native Java applications that can start up in milliseconds, without compromising on throughput, memory, development-production parity, or Java language features? The Open Liberty 22.0.0.11-beta brings you InstantOn, an exciting new feature that provides incredibly fast startup times for MicroProfile and Jakarta EE applications.

In serverless environments, application startup times are important. InstantOn application instances can scale to zero when the application is not in use. Scaling to zero can help reduce the overall cloud costs for deployed applications by reducing the overall number of application instances when there are no ongoing requests. When activity picks up for the application, new instances can start up quickly, without introducing high latency for the user.

How Open Liberty enables InstantOn startup

To enable InstantOn, Open Liberty uses new features of the OpenJ9 JVM and a Linux technology called Checkpoint/Restore In Userspace CRIU to take a checkpoint of the application process as it starts. This checkpoint is a snapshot of the running application process that can be persisted and then quickly restored to bring the application process back into the state it was in when the checkpoint was taken. This process enables the Liberty instance, along with any configured applications, to be restored multiple times into distinct instances of your application.

To see just how fast InstantOn startup is, skip to the "How fast is it?" section. For more details on the advantages of this approach, see the Fast JVM startup with OpenJ9 CRIU Support blog post and this earlier Open Liberty blog post where we first discussed the potential of CRIU for faster startup of Java applications.

The Open Liberty InstantOn feature makes it easy for you to try it out by providing a new checkpoint action, which can be executed against your existing Open Liberty server configurations. With the checkpoint action, you specify a phase at which you want the Liberty startup process to stop and save a checkpoint. When Liberty is launched, it will detect the saved checkpoint process and resume the process from the state that it was saved in during the checkpoint action.

Set up the example application project

Before we get into the details of how the checkpoint action works, let’s set up a working example. For this example, we will have a look at the Getting started with Open Liberty guide. If you want to follow along, start by cloning the Git repository for this guide and use the projects that are provided inside:

git clone https://github.com/openliberty/guide-getting-started.git
cd guide-getting-started

We will work within the finish/ directory for this demonstration. To try out the application, run the following Maven goal to build the application and deploy it to Open Liberty:

cd finish
mvn liberty:run

After you see the following message, your application server is ready:

The defaultServer server is ready to run a smarter planet.

Check out the service at the http://localhost:9080/dev/system/properties URL.

After you finish checking out the application, stop the Open Liberty server by pressing CTRL+C in the command-line session where you ran the server.

To build the WAR for the application run the following :

mvn package

This command builds a target/guide-getting-started.war archive. We can now include this WAR in a container image that uses the InstantOn feature.

Containerizing the application

For an application to use Open Liberty InstantOn support, it must first be containerized using the Open Liberty beta InstantOn image. For general information about how to containerize applications with Open Liberty, see the Containerizing microservices guide or the Containerizing microservices with Podman guide. If you are unfamiliar with Podman, follow the Podman guide first because the Open Liberty InstantOn support currently requires the use of Podman. Support for Docker should come later, once Docker supports the capabilities that CRIU requires.

Containerize an application using the Open Liberty Beta InstantOn image

The Liberty InstantOn beta image contains the prerequisites for building an application container image with a checkpoint server process. Applications can use the Liberty InstantOn beta image as a base to build their own application container images and from that create their own application container image with a checkpoint process. This involves the following steps:

Create the Dockerfile for the application
Build the application container image
Checkpoint an application in-container
Create the application checkpoint image

Prerequisites to checkpoint/restore a containerized application

Currently, the beta of Open Liberty InstantOn only supports running on x86-64/amd64 architectures. To build and run container images that use criu, the host Operating System needs a few prerequisites installed. All our testing was done on RHEL 8.6 and RHEL 9.0. Other Linux distributions and versions might be possible if they have the necessary prerequisites. The following conditions are required:

The kernel must support the Linux CAP_CHECKPOINT_RESTORE capability. This capability was introduced in kernel version 5.9, but was backported to RHEL kernel versions used in RHEL 8.6.
The latest available version of Podman for the Linux distribution must be installed.
Podman must be configured to use the crun or runc container runtime.
If you use the runc container runtime, then version 1.1.3 or higher is required so that you have the recent fix to runc. This fix enables the successful mount of /proc/sys/kernel/ns_last_pid in the container.

Create the Dockerfile for the application

For the Getting started with Open Liberty example, the first step is to create a Dockerfile that provides the instructions to create a containerized version of the application. Note that podman also supports using the Containerfile format for building container images.

For this example, we will use an official image from the IBM Container Registry (ICR), icr.io/appcafe/open-liberty:beta, as the parent image. This image is tagged with the word beta, meaning it includes all the Liberty beta features as well as all the Liberty features from the full image. The image is tagged with instanton, meaning it includes all the prerequisites for producing a checkpoint process image, such as the necessary criu binary files.

The Dockerfile for the getting-started application already exists at finish/Dockerfile. Edit the existing finish/Dockerfile and change the FROM instruction to use the icr.io/appcafe/open-liberty:beta parent image. After you save the Dockerfile, it should look something like this:

Dockerfile

FROM icr.io/appcafe/open-liberty:beta

ARG VERSION=1.0
ARG REVISION=SNAPSHOT

LABEL \
  org.opencontainers.image.authors="Your Name" \
  org.opencontainers.image.vendor="IBM" \
  org.opencontainers.image.url="local" \
  org.opencontainers.image.source="https://github.com/OpenLiberty/guide-getting-started" \
  org.opencontainers.image.version="$VERSION" \
  org.opencontainers.image.revision="$REVISION" \
  vendor="Open Liberty" \
  name="system" \
  version="$VERSION-$REVISION" \
  summary="The system microservice from the Getting Started guide" \
  description="This image contains the system microservice running with the Open Liberty runtime."

COPY --chown=1001:0 src/main/liberty/config/ /config/
COPY --chown=1001:0 target/*.war /config/apps/

RUN configure.sh

Building the application container image

For criu to be able to take a checkpoint of and restore a process, the criu binary must be granted additional Linux capabilities. In particular, for Open Liberty, it needs to be granted cap_checkpoint_restore, cap_net_admin and cap_sys_ptrace. The Open Liberty InstantOn beta image includes the criu binary with the necessary capabilities already granted to the criu binary file. For the criu binary to be given access to its assigned capabilities at run time, the container that is running criu must also be granted the necessary capabilities when it is launched. You can grant these capabilities to the container in one of two ways:

Use a privileged container using the --privileged option
Assign specific capabilities using --cap-add options

When you use Docker, the daemon typically has root authority. This authority allows it to grant any requested capabilities when it launches a container. With Podman, there is no daemon, so the user who launches the container must have the authority to grant it the necessary Linux capabilities. You have this authority when you run as root or use sudo to run the podman commands. For the purposes of this example, we assume you are running the podman commands as the root user.

With that understanding, we can now build the container image by using the podman build command. From the finish/ directory, run the following command to build the container image for the application:

Build the application container image

podman build -t getting-started .

This command creates the getting-started container image. However, this container image does not contain any checkpoint image files that can be used for InstantOn startup. You can run this application container image with the following command:

Run the application container

podman run --name getting-started --rm -p 9080:9080 getting-started

Note the amount of time Liberty takes to report it has been started and check out the service running in the container at the http://localhost:9080/dev/system/properties URL. After you finish checking out the application, stop the running container by pressing CTRL+C in the command-line session where you ran the podman run command.

Checkpoint an application in-container

Open Liberty has three phases during the startup process where a checkpoint can occur:

features - This is the earliest phase where a checkpoint can happen. The checkpoint occurs after all of the configured Open Liberty features are started, but before any processing occurs for the installed applications. Note that this checkpoint phase has been removed, see New enhancements for Liberty InstantOn in 23.0.0.2-beta.
beforeAppStart - The checkpoint happens after processing the configured application metadata. If the application has any components that get run as part of the application starting, the checkpoint is taken before executing any code from the application.
afterAppStart - This is the last phase where a checkpoint can happen, so it has the potential to provide the fastest startup time when restoring the application instance. The checkpoint happens after all configured applications are reported as started. This phase happens before opening any ports for listening to incoming requests for the applications.

The afterAppStart phase typically provides the quickest startup time for an application, but it also might cause some application code to run before the server process checkpoint happens. This might lead to undesired behavior when restoring the checkpoint process if the application holds on to some state that should not be restored into more than one concurrent instance of the application. For example, connecting to an outside resource such as a database before the checkpoint is taken results in a failure to restore many instances of such a process since this would try to restore the same connection multiple times. However, If your application initialization does not perform operations such as opening database connections, you might be able to use the afterAppStart phase for the checkpoint.

After an application container image is built, it can be used to checkpoint the application process at one of the previously described checkpoint phases (features, beforeAppStart, afterAppStart). You can specify a phase for your checkpoint by using the --env option to podman run to set the value for WLP_CHECKPOINT to one of the available checkpoint phases. For this example, use the afterAppStart phase by running the following podman command:

Perform a checkpoint in container

podman run \
  --name getting-started-checkpoint-container \
  --privileged \
  --env WLP_CHECKPOINT=afterAppStart \
  getting-started

The --privileged option is required to perform the criu checkpoint in-container.
The WLP_CHECKPOINT environment variable is used to specify the checkpoint phase. For the getting-started example the afterAppStart checkpoint phase will provide the fastest restore time.

This will start the container with the application running on Open Liberty. After Open Liberty starts, it performs the checkpoint at the phase specified by the WLP_CHECKPOINT environment variable. After the container process data has been persisted, the container will stop, leaving you with a stopped container that contains the checkpoint process data. The output will look something like this:

Process checkpoint output

Performing checkpoint --at=afterAppStart

Launching defaultServer (Open Liberty 22.0.0.11-beta/wlp-1.0.69.cl221020220912-1100) on Eclipse OpenJ9 VM, version 17.0.5-ea+2 (en_US)
CWWKE0953W: This version of Open Liberty is an unsupported early release version.
[AUDIT   ] CWWKE0001I: The server defaultServer has been launched.
[AUDIT   ] CWWKG0093A: Processing configuration drop-ins resource: /opt/ol/wlp/usr/servers/defaultServer/configDropins/defaults/checkpoint.xml
[AUDIT   ] CWWKG0093A: Processing configuration drop-ins resource: /opt/ol/wlp/usr/servers/defaultServer/configDropins/defaults/keystore.xml
[AUDIT   ] CWWKG0093A: Processing configuration drop-ins resource: /opt/ol/wlp/usr/servers/defaultServer/configDropins/defaults/open-default-port.xml
[AUDIT   ] CWWKZ0058I: Monitoring dropins for applications.
[AUDIT   ] CWWKT0016I: Web application available (default_host): http://f5edff273d9c:9080/ibm/api/
[AUDIT   ] CWWKT0016I: Web application available (default_host): http://f5edff273d9c:9080/metrics/
[AUDIT   ] CWWKT0016I: Web application available (default_host): http://f5edff273d9c:9080/health/
[AUDIT   ] CWWKT0016I: Web application available (default_host): http://f5edff273d9c:9080/dev/
[AUDIT   ] CWWKZ0001I: Application guide-getting-started started in 0.986 seconds.
[AUDIT   ] CWWKC0451I: A server checkpoint was requested. When the checkpoint completes, the server stops.

This process currently cannot be done as part of a podman build step because Podman (and Docker) do not provide a way to grant the container image build the necessary Linux capabilities for criu to perform the process checkpoint.

Create the application checkpoint image

So far, we have created the checkpoint process data for the getting-started application and stored it in a stopped container named getting-started-checkpoint-container. The final step is to create a new container image that contains the checkpoint process data. When this container image is started, it will resume the application process right from the point that the checkpoint was created, resulting in an InstantOn application. You can create the new image by running the following podman commit operation:

Commit the checkpoint to an image

podman commit getting-started-checkpoint-container getting-started-instanton

Now we have two application images named getting-started and getting-started-instanton. Starting a container with the getting-started-instanton container image will show a much faster startup time than the original getting-started image.

Running the instanton application image

Typically, an application container can be started from an application container image with a command like the following:

podman run --rm -p 9080:9080 getting-started-instanton

However, this command will fail because criu needs some elevated privileges in order to be able to restore the process in-container. When Liberty fails to restore the checkpoint process, it will recover by launching without the checkpoint image and log the following message:

CWWKE0957I: Restoring the checkpoint server process failed. Check the /logs/checkpoint/restore.log log to determine why the checkpoint process was not restored. Launching the server without using the checkpoint image.

Running with `--privileged` option

To grant all the required privileges available you can choose to launch a privileged container with the following command:

podman run --rm --privileged -p 9080:9080 getting-started-instanton

If successful, you will see output like the following:

[AUDIT   ] CWWKZ0001I: Application guide-getting-started started in 0.059 seconds.
[AUDIT   ] CWWKC0452I: The Liberty server process resumed operation from a checkpoint in 0.088 seconds.
[AUDIT   ] CWWKF0012I: The server installed the following features: [cdi-3.0, checkpoint-1.0, concurrent-2.0, distributedMap-1.0, jndi-1.0, json-1.0, jsonb-2.0, jsonp-2.0, monitor-1.0, mpConfig-3.0, mpHealth-4.0, mpMetrics-4.0, restfulWS-3.0, restfulWSClient-3.0, servlet-5.0, ssl-1.0, transportSecurity-1.0].
[AUDIT   ] CWWKF0011I: The defaultServer server is ready to run a smarter planet. The defaultServer server started in 0.098 seconds.

Running with an unprivileged container

Running fully privileged containers is not recommended. The best practice is to instead reduce the elevated privileges down to only what is required to run the container. You can use the following command to grant the container the necessary privileges without running a fully --privileged container:

podman run with unconfined --security-opt options

podman run \
  --rm \
  --cap-add=CHECKPOINT_RESTORE \
  --cap-add=NET_ADMIN \
  --cap-add=SYS_PTRACE \
  --security-opt seccomp=unconfined \
  --security-opt systempaths=unconfined \
  --security-opt apparmor=unconfined \
  -p 9080:9080 \
  getting-started-instanton

The --cap-add options grant the container the three Linux capabilities that criu requires. The --security-opt options are necessary to grant criu access to the required system calls and access to /proc/sys/kernel/ns_last_pid from the host.

Running with an unprivileged container with confined security

You can further simplify the checkpoint process by reducing the need for the --security-opt options that use unconfined. By default, podman does not grant access to all the system calls that criu needs (defaults specified in the file /usr/share/containers/seccomp.json). First, you need an additional configuration file that grants all the required system calls that criu needs to the container. Second, the host /proc/sys/kernel/ns_last_pid needs to be mounted. You can do both these steps with the following command:

podman run with limited --security-opt

podman run \
  --rm \
  --cap-add=CHECKPOINT_RESTORE \
  --cap-add=NET_ADMIN \
  --cap-add=SYS_PTRACE \
  --security-opt seccomp=criuRequiredSysCalls.json \
  -v /proc/sys/kernel/ns_last_pid:/proc/sys/kernel/ns_last_pid \
  -p 9080:9080 \
  getting-started-instanton

The --security-opt seccomp= option refers to a file called criuRequiredSysCalls.json. This file specifies the system calls required by criu. The -v option mounts the host /proc/sys/kernel/ns_last_pid for access by the container.

Depending on your Linux distribution, Podman might use runc or crun by default. To check what container runtime is configured for your Podman installation, run the command podman info and look at the ociRuntime section. If runc is used, make sure you are using version 1.1.3 or higher. For this method to work, you must have a version of runc that is 1.1.3 or greater.

Depending on how up to date your RHEL 8.6 or RHEL 9.0 installation is, you might find that the --security-opt for specifying the criuRequiredSysCalls.json is unnecessary. At the time of writing, the most up-to-date versions of RHEL 8.6 and RHEL 9.0 include a Podman that grants the required system calls to the containers it launches by default. This default makes specifying the --security-opt seccomp=criuRequiredSysCalls.json unnecessary.

criuRequiredSysCalls.json

{
        "defaultAction": "SCMP_ACT_ERRNO",
        "defaultErrnoRet": 1,
        "archMap": [
                {
                        "architecture": "SCMP_ARCH_X86_64",
                        "subArchitectures": [
                                "SCMP_ARCH_X86",
                                "SCMP_ARCH_X32"
                        ]
                },
                {
                        "architecture": "SCMP_ARCH_AARCH64",
                        "subArchitectures": [
                                "SCMP_ARCH_ARM"
                        ]
                },
                {
                        "architecture": "SCMP_ARCH_MIPS64",
                        "subArchitectures": [
                                "SCMP_ARCH_MIPS",
                                "SCMP_ARCH_MIPS64N32"
                        ]
                },
                {
                        "architecture": "SCMP_ARCH_MIPS64N32",
                        "subArchitectures": [
                                "SCMP_ARCH_MIPS",
                                "SCMP_ARCH_MIPS64"
                        ]
                },
                {
                        "architecture": "SCMP_ARCH_MIPSEL64",
                        "subArchitectures": [
                                "SCMP_ARCH_MIPSEL",
                                "SCMP_ARCH_MIPSEL64N32"
                        ]
                },
                {
                        "architecture": "SCMP_ARCH_MIPSEL64N32",
                        "subArchitectures": [
                                "SCMP_ARCH_MIPSEL",
                                "SCMP_ARCH_MIPSEL64"
                        ]
                },
                {
                        "architecture": "SCMP_ARCH_S390X",
                        "subArchitectures": [
                                "SCMP_ARCH_S390"
                        ]
                },
                {
                        "architecture": "SCMP_ARCH_RISCV64",
                        "subArchitectures": null
                }
        ],
        "syscalls": [
                {
                        "names": [
                                "accept",
                                "accept4",
                                "access",
                                "adjtimex",
                                "alarm",
                                "bind",
                                "brk",
                                "capget",
                                "capset",
                                "chdir",
                                "chmod",
                                "chown",
                                "chown32",
                                "clock_adjtime",
                                "clock_adjtime64",
                                "clock_getres",
                                "clock_getres_time64",
                                "clock_gettime",
                                "clock_gettime64",
                                "clock_nanosleep",
                                "clock_nanosleep_time64",
                                "close",
                                "close_range",
                                "connect",
                                "copy_file_range",
                                "creat",
                                "dup",
                                "dup2",
                                "dup3",
                                "epoll_create",
                                "epoll_create1",
                                "epoll_ctl",
                                "epoll_ctl_old",
                                "epoll_pwait",
                                "epoll_pwait2",
                                "epoll_wait",
                                "epoll_wait_old",
                                "eventfd",
                                "eventfd2",
                                "execve",
                                "execveat",
                                "exit",
                                "exit_group",
                                "faccessat",
                                "faccessat2",
                                "fadvise64",
                                "fadvise64_64",
                                "fallocate",
                                "fanotify_mark",
                                "fchdir",
                                "fchmod",
                                "fchmodat",
                                "fchown",
                                "fchown32",
                                "fchownat",
                                "fcntl",
                                "fcntl64",
                                "fdatasync",
                                "fgetxattr",
                                "flistxattr",
                                "flock",
                                "fork",
                                "fremovexattr",
                                "fsetxattr",
                                "fstat",
                                "fstat64",
                                "fstatat64",
                                "fstatfs",
                                "fstatfs64",
                                "fsync",
                                "ftruncate",
                                "ftruncate64",
                                "futex",
                                "futex_time64",
                                "futex_waitv",
                                "futimesat",
                                "getcpu",
                                "getcwd",
                                "getdents",
                                "getdents64",
                                "getegid",
                                "getegid32",
                                "geteuid",
                                "geteuid32",
                                "getgid",
                                "getgid32",
                                "getgroups",
                                "getgroups32",
                                "getitimer",
                                "getpeername",
                                "getpgid",
                                "getpgrp",
                                "getpid",
                                "getppid",
                                "getpriority",
                                "getrandom",
                                "getresgid",
                                "getresgid32",
                                "getresuid",
                                "getresuid32",
                                "getrlimit",
                                "get_robust_list",
                                "getrusage",
                                "getsid",
                                "getsockname",
                                "getsockopt",
                                "get_thread_area",
                                "gettid",
                                "gettimeofday",
                                "getuid",
                                "getuid32",
                                "getxattr",
                                "inotify_add_watch",
                                "inotify_init",
                                "inotify_init1",
                                "inotify_rm_watch",
                                "io_cancel",
                                "ioctl",
                                "io_destroy",
                                "io_getevents",
                                "io_pgetevents",
                                "io_pgetevents_time64",
                                "ioprio_get",
                                "ioprio_set",
                                "io_setup",
                                "io_submit",
                                "io_uring_enter",
                                "io_uring_register",
                                "io_uring_setup",
                                "ipc",
                                "kill",
                                "landlock_add_rule",
                                "landlock_create_ruleset",
                                "landlock_restrict_self",
                                "lchown",
                                "lchown32",
                                "lgetxattr",
                                "link",
                                "linkat",
                                "listen",
                                "listxattr",
                                "llistxattr",
                                "_llseek",
                                "lremovexattr",
                                "lseek",
                                "lsetxattr",
                                "lstat",
                                "lstat64",
                                "madvise",
                                "membarrier",
                                "memfd_create",
                                "memfd_secret",
                                "mincore",
                                "mkdir",
                                "mkdirat",
                                "mknod",
                                "mknodat",
                                "mlock",
                                "mlock2",
                                "mlockall",
                                "mmap",
                                "mmap2",
                                "mprotect",
                                "mq_getsetattr",
                                "mq_notify",
                                "mq_open",
                                "mq_timedreceive",
                                "mq_timedreceive_time64",
                                "mq_timedsend",
                                "mq_timedsend_time64",
                                "mq_unlink",
                                "mremap",
                                "msgctl",
                                "msgget",
                                "msgrcv",
                                "msgsnd",
                                "msync",
                                "munlock",
                                "munlockall",
                                "munmap",
                                "nanosleep",
                                "newfstatat",
                                "_newselect",
                                "open",
                                "openat",
                                "openat2",
                                "pause",
                                "pidfd_open",
                                "pidfd_send_signal",
                                "pipe",
                                "pipe2",
                                "poll",
                                "ppoll",
                                "ppoll_time64",
                                "prctl",
                                "pread64",
                                "preadv",
                                "preadv2",
                                "prlimit64",
                                "process_mrelease",
                                "pselect6",
                                "pselect6_time64",
                                "pwrite64",
                                "pwritev",
                                "pwritev2",
                                "read",
                                "readahead",
                                "readlink",
                                "readlinkat",
                                "readv",
                                "recv",
                                "recvfrom",
                                "recvmmsg",
                                "recvmmsg_time64",
                                "recvmsg",
                                "remap_file_pages",
                                "removexattr",
                                "rename",
                                "renameat",
                                "renameat2",
                                "restart_syscall",
                                "rmdir",
                                "rseq",
                                "rt_sigaction",
                                "rt_sigpending",
                                "rt_sigprocmask",
                                "rt_sigqueueinfo",
                                "rt_sigreturn",
                                "rt_sigsuspend",
                                "rt_sigtimedwait",
                                "rt_sigtimedwait_time64",
                                "rt_tgsigqueueinfo",
                                "sched_getaffinity",
                                "sched_getattr",
                                "sched_getparam",
                                "sched_get_priority_max",
                                "sched_get_priority_min",
                                "sched_getscheduler",
                                "sched_rr_get_interval",
                                "sched_rr_get_interval_time64",
                                "sched_setaffinity",
                                "sched_setattr",
                                "sched_setparam",
                                "sched_setscheduler",
                                "sched_yield",
                                "seccomp",
                                "select",
                                "semctl",
                                "semget",
                                "semop",
                                "semtimedop",
                                "semtimedop_time64",
                                "send",
                                "sendfile",
                                "sendfile64",
                                "sendmmsg",
                                "sendmsg",
                                "sendto",
                                "setfsgid",
                                "setfsgid32",
                                "setfsuid",
                                "setfsuid32",
                                "setgid",
                                "setgid32",
                                "setgroups",
                                "setgroups32",
                                "setitimer",
                                "setpgid",
                                "setpriority",
                                "setregid",
                                "setregid32",
                                "setresgid",
                                "setresgid32",
                                "setresuid",
                                "setresuid32",
                                "setreuid",
                                "setreuid32",
                                "setrlimit",
                                "set_robust_list",
                                "setsid",
                                "setsockopt",
                                "set_thread_area",
                                "set_tid_address",
                                "setuid",
                                "setuid32",
                                "setxattr",
                                "shmat",
                                "shmctl",
                                "shmdt",
                                "shmget",
                                "shutdown",
                                "sigaltstack",
                                "signalfd",
                                "signalfd4",
                                "sigprocmask",
                                "sigreturn",
                                "socket",
                                "socketcall",
                                "socketpair",
                                "splice",
                                "stat",
                                "stat64",
                                "statfs",
                                "statfs64",
                                "statx",
                                "symlink",
                                "symlinkat",
                                "sync",
                                "sync_file_range",
                                "syncfs",
                                "sysinfo",
                                "tee",
                                "tgkill",
                                "time",
                                "timer_create",
                                "timer_delete",
                                "timer_getoverrun",
                                "timer_gettime",
                                "timer_gettime64",
                                "timer_settime",
                                "timer_settime64",
                                "timerfd_create",
                                "timerfd_gettime",
                                "timerfd_gettime64",
                                "timerfd_settime",
                                "timerfd_settime64",
                                "times",
                                "tkill",
                                "truncate",
                                "truncate64",
                                "ugetrlimit",
                                "umask",
                                "uname",
                                "unlink",
                                "unlinkat",
                                "utime",
                                "utimensat",
                                "utimensat_time64",
                                "utimes",
                                "vfork",
                                "vmsplice",
                                "wait4",
                                "waitid",
                                "waitpid",
                                "write",
                                "writev",
                                "arch_prctl",
                                "chroot",
                                "clone",
                                "clone3",
                                "fallocate",
                                "fanotify_init",
                                "fsconfig",
                                "fsmount",
                                "fsopen",
                                "guarded_storage",
                                "kcmp",
                                "lseek",
                                "mmap",
                                "mount",
                                "open",
                                "open_by_handle_at",
                                "openat",
                                "pivot_root",
                                "preadv",
                                "process_vm_readv",
                                "ptrace",
                                "readdir",
                                "s390_runtime_instr",
                                "setns",
                                "sigaction",
                                "signal",
                                "syscall",
                                "umount",
                                "umount2",
                                "unshare",
                                "userfaultfd",
                                "wait"
                        ],
                        "action": "SCMP_ACT_ALLOW"
                },
                {
                        "names": [
                                "process_vm_readv",
                                "process_vm_writev",
                                "ptrace"
                        ],
                        "action": "SCMP_ACT_ALLOW",
                        "includes": {
                                "minKernel": "4.8"
                        }
                },
                {
                        "names": [
                                "personality"
                        ],
                        "action": "SCMP_ACT_ALLOW",
                        "args": [
                                {
                                        "index": 0,
                                        "value": 0,
                                        "op": "SCMP_CMP_EQ"
                                }
                        ]
                },
                {
                        "names": [
                                "personality"
                        ],
                        "action": "SCMP_ACT_ALLOW",
                        "args": [
                                {
                                        "index": 0,
                                        "value": 8,
                                        "op": "SCMP_CMP_EQ"
                                }
                        ]
                },
                {
                        "names": [
                                "personality"
                        ],
                        "action": "SCMP_ACT_ALLOW",
                        "args": [
                                {
                                        "index": 0,
                                        "value": 131072,
                                        "op": "SCMP_CMP_EQ"
                                }
                        ]
                },
                {
                        "names": [
                                "personality"
                        ],
                        "action": "SCMP_ACT_ALLOW",
                        "args": [
                                {
                                        "index": 0,
                                        "value": 131080,
                                        "op": "SCMP_CMP_EQ"
                                }
                        ]
                },
                {
                        "names": [
                                "personality"
                        ],
                        "action": "SCMP_ACT_ALLOW",
                        "args": [
                                {
                                        "index": 0,
                                        "value": 4294967295,
                                        "op": "SCMP_CMP_EQ"
                                }
                        ]
                },
                {
                        "names": [
                                "sync_file_range2",
                                "swapcontext"
                        ],
                        "action": "SCMP_ACT_ALLOW",
                        "includes": {
                                "arches": [
                                        "ppc64le"
                                ]
                        }
                },
                {
                        "names": [
                                "arm_fadvise64_64",
                                "arm_sync_file_range",
                                "sync_file_range2",
                                "breakpoint",
                                "cacheflush",
                                "set_tls"
                        ],
                        "action": "SCMP_ACT_ALLOW",
                        "includes": {
                                "arches": [
                                        "arm",
                                        "arm64"
                                ]
                        }
                },
                {
                        "names": [
                                "arch_prctl"
                        ],
                        "action": "SCMP_ACT_ALLOW",
                        "includes": {
                                "arches": [
                                        "amd64",
                                        "x32"
                                ]
                        }
                },
                {
                        "names": [
                                "modify_ldt"
                        ],
                        "action": "SCMP_ACT_ALLOW",
                        "includes": {
                                "arches": [
                                        "amd64",
                                        "x32",
                                        "x86"
                                ]
                        }
                },
                {
                        "names": [
                                "s390_pci_mmio_read",
                                "s390_pci_mmio_write",
                                "s390_runtime_instr"
                        ],
                        "action": "SCMP_ACT_ALLOW",
                        "includes": {
                                "arches": [
                                        "s390",
                                        "s390x"
                                ]
                        }
                },
                {
                        "names": [
                                "riscv_flush_icache"
                        ],
                        "action": "SCMP_ACT_ALLOW",
                        "includes": {
                                "arches": [
                                        "riscv64"
                                ]
                        }
                },
                {
                        "names": [
                                "open_by_handle_at"
                        ],
                        "action": "SCMP_ACT_ALLOW",
                        "includes": {
                                "caps": [
                                        "CAP_DAC_READ_SEARCH"
                                ]
                        }
                },
                {
                        "names": [
                                "bpf",
                                "clone",
                                "clone3",
                                "fanotify_init",
                                "fsconfig",
                                "fsmount",
                                "fsopen",
                                "fspick",
                                "lookup_dcookie",
                                "mount",
                                "mount_setattr",
                                "move_mount",
                                "name_to_handle_at",
                                "open_tree",
                                "perf_event_open",
                                "quotactl",
                                "quotactl_fd",
                                "setdomainname",
                                "sethostname",
                                "setns",
                                "syslog",
                                "umount",
                                "umount2",
                                "unshare"
                        ],
                        "action": "SCMP_ACT_ALLOW",
                        "includes": {
                                "caps": [
                                        "CAP_SYS_ADMIN"
                                ]
                        }
                },
                {
                        "names": [
                                "clone"
                        ],
                        "action": "SCMP_ACT_ALLOW",
                        "args": [
                                {
                                        "index": 0,
                                        "value": 2114060288,
                                        "op": "SCMP_CMP_MASKED_EQ"
                                }
                        ],
                        "excludes": {
                                "caps": [
                                        "CAP_SYS_ADMIN"
                                ],
                                "arches": [
                                        "s390",
                                        "s390x"
                                ]
                        }
                },
                {
                        "names": [
                                "clone"
                        ],
                        "action": "SCMP_ACT_ALLOW",
                        "args": [
                                {
                                        "index": 1,
                                        "value": 2114060288,
                                        "op": "SCMP_CMP_MASKED_EQ"
                                }
                        ],
                        "comment": "s390 parameter ordering for clone is different",
                        "includes": {
                                "arches": [
                                        "s390",
                                        "s390x"
                                ]
                        },
                        "excludes": {
                                "caps": [
                                        "CAP_SYS_ADMIN"
                                ]
                        }
                },
                {
                        "names": [
                                "clone3"
                        ],
                        "action": "SCMP_ACT_ERRNO",
                        "errnoRet": 38,
                        "excludes": {
                                "caps": [
                                        "CAP_SYS_ADMIN"
                                ]
                        }
                },
                {
                        "names": [
                                "reboot"
                        ],
                        "action": "SCMP_ACT_ALLOW",
                        "includes": {
                                "caps": [
                                        "CAP_SYS_BOOT"
                                ]
                        }
                },
                {
                        "names": [
                                "chroot"
                        ],
                        "action": "SCMP_ACT_ALLOW",
                        "includes": {
                                "caps": [
                                        "CAP_SYS_CHROOT"
                                ]
                        }
                },
                {
                        "names": [
                                "delete_module",
                                "init_module",
                                "finit_module"
                        ],
                        "action": "SCMP_ACT_ALLOW",
                        "includes": {
                                "caps": [
                                        "CAP_SYS_MODULE"
                                ]
                        }
                },
                {
                        "names": [
                                "acct"
                        ],
                        "action": "SCMP_ACT_ALLOW",
                        "includes": {
                                "caps": [
                                        "CAP_SYS_PACCT"
                                ]
                        }
                },
                {
                        "names": [
                                "kcmp",
                                "pidfd_getfd",
                                "process_madvise",
                                "process_vm_readv",
                                "process_vm_writev",
                                "ptrace"
                        ],
                        "action": "SCMP_ACT_ALLOW",
                        "includes": {
                                "caps": [
                                        "CAP_SYS_PTRACE"
                                ]
                        }
                },
                {
                        "names": [
                                "iopl",
                                "ioperm"
                        ],
                        "action": "SCMP_ACT_ALLOW",
                        "includes": {
                                "caps": [
                                        "CAP_SYS_RAWIO"
                                ]
                        }
                },
                {
                        "names": [
                                "settimeofday",
                                "stime",
                                "clock_settime"
                        ],
                        "action": "SCMP_ACT_ALLOW",
                        "includes": {
                                "caps": [
                                        "CAP_SYS_TIME"
                                ]
                        }
                },
                {
                        "names": [
                                "vhangup"
                        ],
                        "action": "SCMP_ACT_ALLOW",
                        "includes": {
                                "caps": [
                                        "CAP_SYS_TTY_CONFIG"
                                ]
                        }
                },
                {
                        "names": [
                                "get_mempolicy",
                                "mbind",
                                "set_mempolicy"
                        ],
                        "action": "SCMP_ACT_ALLOW",
                        "includes": {
                                "caps": [
                                        "CAP_SYS_NICE"
                                ]
                        }
                },
                {
                        "names": [
                                "syslog"
                        ],
                        "action": "SCMP_ACT_ALLOW",
                        "includes": {
                                "caps": [
                                        "CAP_SYSLOG"
                                ]
                        }
                }
        ]
}

How fast is it?

We tested multiple applications to show how startup time is reduced with InstantOn.

Pingperf is a very simple ping-type application involve a single REST endpoint.
Rest crud is a bit more complicated, and involves JPA and a remote database.
AcmeAir Microservice Main makes use of the MicroProfile features.

These experiments were run on a 24 core system. I used taskset -c to allocate 4 CPUs to the Liberty process running in container. The InstantOn times were taken using the afterAppStart checkpoint phase. Startup time is measured from the time the Liberty server startup is initiated to the time the server is ready to accept requests, as denoted by the message "The <server name> server is ready to run a smarter planet." in the messages.log. The time it takes to start the container itself up has been filtered out. InstantOn versus normal startup times for these applications are shown here in milliseconds. Your results may vary based on your environment, hardware and software installed on your system, and other factors. Lower is better:

InstantOn offers a large startup savings of up to 90% depending on the application. All applications are not the same, so you might see different results with your applications.

What is next?

This post described the details of using Open Liberty InstantOn beta to produce an application container image with InstantOn startup times. This support currently allows for only Open Liberty features that are included as part of the Liberty webProfile-8.0, webProfile-9.1, microProfile-4.1 and microProfile-5.0 umbrella features. We hope to expand that to include future versions of webProfile and microProfile, as well as to expand support to the Jakarta full profile features (e.g. jakarta-8.0, jakarta-9.1, jakarta-10.0).

With InstantOn, you can build very fast startup application containers that can be deployed with scale-to-zero as an option. We look forward to a future blog post that describes how to deploy Open Liberty InstantOn in cloud environments such as Red Hat OpenShift Container Platform (OCP) and Kubernetes (k8s) with technologies that can auto-scale applications to zero, such as Knative.

InstantOn with checkpoint/restore in Open Liberty 22.0.0.11-beta!

Thu, 29 Sep 2022 00:00:00 +0000

Open Liberty 22.0.0.11-beta provides an exciting new capability called InstantOn, which provides incredibly fast startup times and can help reduce the overall cloud costs for cloud-native applications.

Since the 22.0.0.9-beta release, which included the Jakarta EE 10 Core Profile, Open Liberty has continued to beta more and more Jakarta EE 10 features. This beta release introduces various developer experience and performance enhancements available through the following new Jakarta EE 10 features: Servlet 6.0, Mail 2.1, Connectors 2.1 and Persistance 3.1.

The Open Liberty 22.0.0.11-beta includes the following new beta features (along with all GA features):

InstantOn with checkpoint/restore
Jakarta EE 10 Updates

InstantOn with checkpoint/restore

Traditionally, starting an application can take several seconds, and sometimes minutes, before the application can service its first request. Longer startup times inhibit an application’s ability to scale to zero when deployed in a cloud environment such as Kubernetes, which in turn can drive up costs.

Liberty’s InstantOn capability is an innovative way to drastically reduce that startup time by using checkpoint/restore. Restoring an application from a checkpoint process can be up to 10 times faster than starting the Liberty application from the beginning.

For more information, see the Liberty InstantOn startup for cloud native Java applications blog post.

Jakarta EE 10 Updates

With the 22.0.0.11-beta release, Open Liberty adds four more Jakarta EE 10 features: Mail 2.1, Servlet 6.0, Connectors 2.1 and Persistance 3.1. These four features join the Jakarta EE 10 features from previous beta releases, including those that make up the Jakarta EE 10 Core Profile. To review all the previous beta content, take a look at the recent beta blog posts.

Set any cookie attribute (Jakarta Servlet 6.0)

The Open Liberty Jakarta Servlet 6.0 (servlet-6.0) feature is an implementation of the Jakarta EE 10 Servlet 6.0 specification. It includes a number of new features, specification clarifications, and deprecation features.

Before Jakarta Servlet 6.0, only a few specific methods could be set for an application’s cookie attributes. This meant that an application could not easily set a new attribute, such as the recent browser security SameSite attribute.

One of the new features in Jakarta Servlet 6.0 is the ability to set any attribute using a cookie’s setAttribute method. In addition, Jakarta Servlet 6.0 also introduces some new request APIs to aid the application’s debugging. Application developers can track or refer to a request using the ServletRequest() getRequestId() method or obtain details of the network connection that is being used by the request by calling ServletRequest() getServletConnection() method.

You can enable the feature by adding servlet-6.0 to your server.xml:

  <featureManager>
    <feature>servlet-6.0</feature>
  </featureManager>

For more information, refer to the Jakarta Servlet 6.0 Specification and Javadocs.

Simpler Jakarta Mail code compilation (Jakarta Mail 2.1)

Jakarta Mail 2.1 support allows your Jakarta EE 10 applications to send, read, and edit E-Mail from mail servers via the Jakarta Mail APIs.

The biggest change to the Jakarta Mail 2.1 specification is the removal of the direct dependency of the specification APIs on the reference implementation. This means that, in certain cases, there is no longer a need to compile your Jakarta Mail code against both the specification and the reference implementation (provided you aren’t making any direct calls to the reference implementation in your code).

To facilitate this improvement, Jakarta Mail 2.1 also introduces the jakarta.mail.util.StreamProvider utility interface, which can be easily obtained with the jakarta.mail.Session.getStreamProvider() method. You can then use the StreamProviders instance to obtain encoded/decoded streams for any of the encoding/decoding methods that Jakarta Mail 2.1 supports.

You can enable the feature by adding mail-2.1 to your server.xml:

  <featureManager>
    <feature>mail-2.1</feature>
  </featureManager>

For more information about the Jakarta Mail 2.1 specification, check out the Jakarta Mail project website.

Ensure correctness of data types (Jakarta Connectors 2.1)

Jakarta Connectors standardizes how connectors to various enterprise information systems interact with the container and applications. Jakarta Connectors 2.1 enables you to use the latest release of the Jakarta resource specification in your application.

The main update to Jakarta Connectors in this minor feature version update is the addition of Java generics support to the jakarta.resource.cci.ResourceFactory, jakarta.resource.cci.IndexedRecord, and jakarta.resource.cci.MappedRecord classes. This helps avoid compiler warnings and also helps ensure correctness of data types during development time.

You can enable the feature by adding connectors-2.1 to your server.xml:

  <featureManager>
    <feature>connectors-2.1</feature>
  </featureManager>

All other resourceAdapter configurations within server.xml can remain unchanged for current applications.

You can find out more about this specific update with the following links:

JPQL and Criteria API enhancements (Jakarta Persistence 3.1)

Jakarta Persistence API (JPA) is a richly featured API that provides an object-model approach to persisting, fetching, and modifying data stored on a relational database system. Prior to the introduction of JPA in Java EE 5, in order to interact with database storage, you had to use EJB bean or container managed entities, or raw JDBC.

Jakarta Persistence 3.1 is a minor version update but introduces some great new capabilities. You can now take advantage of the AutoClosable interface, introduced in Java 7, which allows for resources declared in a try-with-resources block to be automatically closed upon the completion of that try block. Other new features include the ability to use fields of type java.lang.UUID as @Id types and enhancements to Java Persistence Query Language (JPQL) and Criteria API.

You can enable the feature by adding persistence-3.1 to your server.xml:

  <featureManager>
    <feature>persistence-3.1</feature>
  </featureManager>

Try it now

To try out these features, just update your build tools to pull the Open Liberty All Beta Features package instead of the main release. The beta works with Java SE 19, Java SE 18, Java SE 17, Java SE 11, and Java SE 8.

If you’re using Maven, here are the coordinates:

<dependency>
  <groupId>io.openliberty.beta</groupId>
  <artifactId>openliberty-runtime</artifactId>
  <version>22.0.0.11-beta</version>
  <type>pom</type>
</dependency>

Or for Gradle:

dependencies {
    libertyRuntime group: 'io.openliberty.beta', name: 'openliberty-runtime', version: '[22.0.0.11-beta,)'
}

Or take a look at our Downloads page.

We welcome your feedback

Let us know what you think on our mailing list. If you hit a problem, post a question on StackOverflow. If you hit a bug, please raise an issue.

Open Liberty: A brief history in maker projects of a cloud-native Java runtime

Wed, 21 Sep 2022 00:00:00 +0000

Five years ago, in 2017, IBM published the source code of Liberty, its cloud-native Java runtime, on GitHub as the Open Liberty project. Liberty was actually born five years earlier, in 2012 (we recently celebrated its 10th birthday), to address the need for a small footprint, extensible, and easily configurable Java runtime that could run on the cloud as well as in a data centre. Liberty was designed to provide a friendly experience to developers as well as to be powerful and flexible at runtime.

At the time, Java runtimes were mostly big and serious, but Liberty was different and Liberty’s development team were inspired to make it fun. The crafters and makers in the team got to work on physical projects that used or represented Liberty in creative ways.

The first Java runtime on a Raspberry Pi

Liberty was the first Java runtime to run on a Raspberry Pi. Even before Liberty’s first release, Simon Maple (Liberty’s first developer advocate) and Ozzy Osbourne (not that one; this one) ran Liberty on a pre-release Raspberry Pi, which had just 700 Mhz of processing power and 256 MB of memory. Simon went on to demonstrate Liberty’s applicability to the early Internet of Things by running Liberty and MQTT on a Raspberry Pi to remotely control a smart house 50 miles away.

Running Liberty on the Raspberry Pi in 2012. Photo by Simon Maple.

Running Liberty on a Raspberry Pi and other hardware with limited resources sparked the imaginations of the makers within the development team.

Early Liberty conference demos of Java EE on Liberty

One much-travelled Liberty conference demo was the remote-controlled Liberty Car, the creation of Simon’s successor, Tom Banks (also responsible for creating a Minecraft user interface to Liberty) and Ozzy. Tom replaced the guts of a remote-controlled car with a Raspberry Pi running Liberty plus a WiFi access point.

Remote controlled car with embedded Arduino running Liberty.

Any conference attendee could connect and control the car from their own smartphone, demonstrating, among other things, the responsiveness of 2013’s Java EE 7 WebSocket technology. Java EE, not then known for its small, lightweight footprint, ran easily on the limited hardware resources. Tom’s Liberty Car project matured into a conference game where attendees could race multiple Liberty Cars around a large race-track. Check out the YouTube video where Tom talks through how it works.

Wearable and throwable infrastructures

Liberty can run with only a tiny footprint, making it friendly to both developer laptops and the cloud. This was enabled by its original OSGi architecture, which meant that any app running on Liberty could start with just minimal capabilities and then add and remove features on the fly at run time as needed by the app, including features of the recently released Java EE 7.

Queen of Enterprise OSGi and the unconventional conference demo, Holly Cummins briefly made wearing a Java runtime as a hat into a thing. She sewed a Raspberry Pi into a chef’s hat and ran Liberty on it. She then wore it when presenting at conferences to show that you can take servers with you to run outside of big data centres, for example in disaster zones or other environments where there isn’t the usual internet infrastructure.

Holly presenting in her chef’s hat at JFokus. Photo by Kate Stanley.

Check out the YouTube video where Holly talks about her wearable Java runtime.

After a couple of years of sporting a chef’s hat at Enterprise Java conferences, Holly went further with her Java runtime crafting and made a cuddly throwable Java runtime. This was an actual cuddly ball with LEDs and a Raspberry Pi embedded in it. She would throw the ball into the audience part-way through her talk and encourage them to chuck it around the room during her presentations.

Holly about to throw her app server ball whilst presenting at QCon.

Cloud-native Java microservices games

As the industry moved to microservices, Enterprise Java evolved into the more microservices-friendly Eclipse MicroProfile and Eclipse Jakarta EE, for which the Liberty development team are actively involved in developing and implementing specifications. So Liberty crafters and makers moved to building demos with microservice architectures rather than single-server applications. Open Liberty’s new bright space-related branding also lent itself well to 3D-printed spaceships and space-themed games (and a virtual bike racing game).

3D-printed spaceship shell for a toy car by Martin Holder and Mike Bettle-Shaffer. Photo by Mike Bettle-Shaffer.

Space Sentry was a game built by Prashanth Gunapalasingam and Frank Ji on Java microservices. Players controlled a laser that was mounted on top of a 3D-printed spaceship to fire at 3D-printed targets. The movements were handled by Lego and Arduinos that communicated over Wi-Fi with three microservices running in Open Liberty containers on a Raspberry Pi.

The three microservices communicated with each other using REST APIs (JAX-RS and MicroProfile Rest Client), and used other MicroProfile 2.2 features such as MicroProfile Config, MicroProfile Health, and MicroProfile Metrics to configure and monitor the services and to post results on the leaderboard.

Space Sentry spaceship and laser. Photo by the Space Sentry team.

The next generation of space-themed microservices-based games came more recently in the form of Space Rover.

Space Rover is a shiny, open source game that has a Java microservices architecture and uses Jakarta EE 9.1 and MicroProfile 5.0 APIs. It has a physical board, made by Ellen Lau from wood and acrylic sheets with LED lights that mark out the asteroids on the board and give feedback when the Space Rover drives over the asteroid and when it completes the level. The 3D-printed Space Rover, also made by Prashanth, runs on a chassis with wheels and it rolls around the board in response to hand gestures captured by a webcam.

Space Rover game board. Photo by the Space Rover team.

Space Rover scoreboard.

Space Rover’s services make extensive use of web sockets to communicate between the components of the game (Jakarta WebSocket 2.0) and other Jakarta EE 9.1 technologies including REST endpoints and HTTP endpoints for communicating with the leaderboard and handling the game statistics (Jakarta JAX-RS 3.0), and database injections for interacting with the leaderboard database (Jakarta CDI 3.0).

MicroProfile 5.0 technologies are used to check the status of the services and database (MicroProfile Health 4.0); to configure connections to different services and database (MicroProfile Config 3.0); to retry connection attempts to the database when there are problems (MicroProfile Fault Tolerance 4.0); to record JVM metrics on the Game service and track the latency of the Game service for the health check test (MicroProfile Metrics 4.0); to generate an HTTP client to send game end statistics to the leaderboard (MicroProfile Rest Client 3.0); and to provide REST API documentation and a UI for demonstration (MicroProfile OpenAPI 3.0).

Space Rover architecture diagram by the Space Rover team.

Ellen, Prashanth, and team take Space Rover to conferences around the world (including Atlanta, Texas, Chicago, UK, and Ireland) where they invite attendees to use hand gestures to drive the Space Rover around the board without running into asteroids.

Inspired by Open Liberty

And finally, Open Liberty has also inspired projects like this Open Liberty logo made by Christopher Regan from wood and acrylic on a laser cutter:

Open Liberty lasercut logo. Photo by Christopher Regan

And an Open Liberty mug rug can brighten up your desk and provide somewhere to host your tea and biscuits (or your Java and cookies, if you prefer). If you want to make your own mug rug, you can find the template and some instructions in GitHub.

Open Liberty logo mug rug mini quilt.

Liberty today

Open Liberty, the cloud-native Java runtime, celebrates its 5th birthday as an open source project. It continues to be the upstream source for IBM’s commercial Liberty runtime and the development team continues to contribute to and support Eclipse MicroProfile, Eclipse Jakarta EE, Eclipse OpenJ9, and other related open source projects.

Liberty’s crafters and makers will no doubt continue to develop creative new ideas alongside their day jobs. If you have created something of your own (like Roberto and his son who monitored their lizard enclosure using Liberty), let us know!

If you would like to learn more about Liberty, try our guides.

All photos were taken by Laura Cowen unless otherwise noted.

Try out Eclipse Cargo Tracker, an enterprise-level Jakarta EE application, with Open Liberty

Wed, 24 Aug 2022 00:00:00 +0000

As one of the top Java framework choices for enterprise-level applications, Jakarta EE is at the center of projects all over the globe. The Eclipse Cargo Tracker open-source application was designed to replicate a complex enterprise application by using core Jakarta EE features with professional development standards. Now, you can get a taste of Open Liberty in an industrial environment by running Cargo Tracker with an Open Liberty server, all on your own computer.

The Cargo Tracker application

Cargo Tracker simulates an industrially-developed freight tracking web application built with Jakarta EE 8 and domain-driven design principles. The application uses key Jakarta EE features, including Faces, CDI, Enterprise Beans, Bean Validation, RESTful Web Services, and JSON Binding. It also uses Persistence, along with Batch and Messaging.

Cargo Tracker books, tracks, updates, and routes cargo objects. Messaging events are logged to update cargo locations, while persistence ensures that cargo status is not changed or removed when the application is shut down. Each portion of Cargo Tracker represents a step in a real-life shipment process: the customer tracks their cargo using the Public Tracking interface, the shipping company schedules and routes deliveries using the Administration interface, and port handlers log arriving and departing cargo using the Mobile Event Logger.

Try out Cargo Tracker with Open Liberty

Feel free to give Cargo Tracker with Open Liberty a try on your own! Cargo Tracker supports Java SE 8, 11, and 17. IBM Semeru Runtime is the preferred Java runtime when using Open Liberty. Before you clone the application to your machine, install any required JDKs and ensure that your JAVA_HOME system variable is set to a compatible version. To access the repository remotely you’ll need to install Git if you haven’t already. Finally, you will need to install Maven to build and run the application.

You can clone the Open Liberty branch of the Cargo Tracker project to your local machine by running:

git clone https://github.com/eclipse-ee4j/cargotracker.git -b liberty-experimental

You can also visit the Git repository for the Open Liberty branch of the Cargo Tracker project to take a peek at the code.

To get started, choose one of the following setup methods:

Maven command line setup
Eclipse IDE setup

Maven command line setup

After cloning the project, you can quickly start Cargo Tracker through the command line with Maven. Navigate to the project base directory (where the pom.xml file is located) and run:

mvn -P openliberty liberty:dev

The application should start without any thrown exceptions. Startup messages, such as the message-driven bean activation warnings, are cosmetic and can be safely ignored.

Eclipse IDE setup

You’ll need Eclipse IDE version 2022-03 or later to run the application. Either the "Eclipse IDE for Java Developers" or "Eclipse IDE for Enterprise Java and Web Developers" package will work.

After you clone the project, import it into Eclipse by selecting the File menu and then Import. Choose the Existing Maven Projects option inside the Import menu.

In the next step, select the repository base folder as the root directory and check the pom.xml under the Maven Projects tab. Select Finish to complete the import process.

If you’re working inside the Eclipse IDE, you’ll need to install IBM’s Liberty Tools feature. Follow the steps in the installation guide to access some convenient new resources and operations that are specific to Liberty. This blog post covers the feature’s capabilities in more detail, but for now we’ll focus on the Liberty Dashboard.

To run Cargo Tracker, right-click the cargo-tracker project and select the Start… option, which is second in the list.

You can then run dev mode with the Open Liberty profile active by typing in -Popenliberty.

After starting with the custom parameters for the Open Liberty profile, the application should start inside the Eclipse terminal.

Avoid trouble - set environment variables

Since the Liberty Tools feature uses the well-known environment variables: PATH and JAVA_HOME, you will encounter problems if these variables are not set within your Eclipse IDE process, e.g. the mvn executable might not be found.

One tip to address this on Mac OS in particular is to restart Eclipse through Finder by right-clicking your Eclipse application and choosing Show Package Contents. Enter the newly displayed Contents folder, select MacOS, and then run Eclipse by clicking the executable.

Access the application

Once the application is running, you can access it through a browser of your choice at http://localhost:8080/cargo-tracker/ and start experimenting with it. You can track routed cargo through the Public Tracking interface, book and route cargo through the Administration interface (shown in the following image), and update cargo object events using the Mobile Event Logger. You can stop the server at any time by using CTRL-C.

For more information about of each of the interfaces, can check out the Exploring the Application section of the project README.

The README.md also contains step by step instructions for starting the application along with detailed explanations for each of the interface options on the home page.

Nice work! Where to next?

You’ve just set up Cargo Tracker and experienced Open Liberty with an enterprise-level application on your own machine! Check out the Open Liberty guides for more information on using Jakarta EE and MicroProfile with Open Liberty.

Helpful links

Jakarta EE 10 Core Profile debuts in Open Liberty 22.0.0.9-beta

Thu, 04 Aug 2022 00:00:00 +0000

Open Liberty 22.0.0.9-beta brings you the hot-off-the-press Jakarta EE 10 Core Profile. Jakarta EE 10 will be the first release to provide updates to the specifications since Java EE 8 in 2017. Jakarta EE 10 Core Profile is a subset of the specifications. The Core Profile is specifically aimed at lightweight runtimes, like Open Liberty, that are optimised for running cloud-native Java microservices. While the whole Jakarta EE 10 release is just around the corner, Open Liberty 22.0.0.9-beta provides a preview of the Core Profile subset of features for you to start exploring now.

As well as Jakarta EE 10 Core Profile, we’ve included in this beta two other Jakarta EE features: Jakarta EE 10 Expression Language 5.0, which means you can access any annotations present on a particular method using the getAnnotations() method, and more; and Jakarta Concurrency 3.0, which enhances the set of parallel and reactive programming models available to applications, and more.

But it’s not only Jakarta EE features in this release: MicroProfile OpenAPI 3.1 provides the ability to specify optional authentication for operations and multiple annotation enhancements, and Password Utilities 1.1 no longer forcefully federates stand-alone user registries.

The Open Liberty 22.0.0.9-beta includes the following beta features (along with all GA features):

Jakarta EE 10 Core Profile:
Jakarta EE 10:
- Access any available annotations using getAnnotations() (Jakarta Expression Language 5.0)
- Enhanced parallel and reactive programming models available to applications (Jakarta Concurrency 3.0)
Document APIs where authentication is optional or complex (MicroProfile OpenAPI 3.1)
Stand-alone user registries no longer forcefully federated (Password Utilities 1.1)

Support for multipart/form-data content type (RESTful Web Services 3.1)

Jakarta RESTful Web Services 3.1 (also known as Jakarta Rest 3.1 and formerly known as JAX-RS) is now available in the Open Liberty 22.0.0.9 beta. The 3.1 implementation is based on RESTEasy and is an EE10 technology, which uses the jakarta.* package name. For more information on the changes in this release, see the Changes Since 3.0 Release section of the Jakarta RESTful Web Services Spec.

Give it a try - and if you encounter any issues, please let us know!

You can enable RESTful Web Services 3.1 by using the restfulWS-3.1 feature in your server.xml file:

<featureManager>
  <feature>restfulWS-3.1</feature>
</featureManager>

If you only need a RESTful client, use the restfulWSClient-3.1 feature instead:

<featureManager>
  <feature>restfulWSClient-3.1</feature>
</featureManager>

To learn more about RESTful Web Services or see what is coming in future releases, visit the EE4J community page.

Enhanced JSON string parsing and new serialization/deserialization options (JSON Processing 2.1 and JSON Binding 3.0)

The Jakarta JSON Processing specification enables you to parse and generate JSON strings. The Jakarta JSON Binding specification is built on top of JSON Processing and enables you to serialize and deserialize Java objects into JSON.

The Jakarta JSON Processing specification has been updated with enhancements for handling duplicate keys when parsing JSON, and better handling of the java.lang.Number superclass when generating JSON strings. The Jakarta JSON Binding specification has been updated to support polymorphism.

Open Liberty provides default implementations for both Jakarta JSON Processing and Binding. For JSON Processing, we provide the Parsson implementation. For JSON Binding, we provide the Yasson implementation. To get these default implementations you can enable the jsonp-2.1 and jsonb-3.0 features.

<featureManager>
    <feature>jsonb-3.0</feature>
    <feature>jsonp-2.1</feature>
</featureManager>

If you want to use a third-party Jakarta JSON Processing 2.1 or Binding 3.0 implementation, you can enable the jsonpContainer-2.1 or jsonbContainer-3.0 features. The JSON Container features require you to configure a Basic Extensions using Liberty Libraries (BELLs) element that points to your third-party implementation(s).

<featureManager>
    <feature>jsonbContainer-3.0</feature>
    <feature>jsonpContainer-2.1</feature>
</featureManager>

<library id="myJsonBindingProvider">
  <file name="${path.to.json.binding.provider}"/>
</library>

<bell libraryRef="myJsonBindingProvider"/>

<library id="myJsonProcessingProvider">
  <file name="${path.to.json.processing.provider}"/>
</library>

<bell libraryRef="myJsonProcessingProvider"/>

Note that enabling either the JSON-B 3.0 feature (jsonb-3.0) or the JSON-B Container 3.0 (jsonbContainer-3.0) feature automatically enables the JSON-P 2.1 feature (jsonp-2.1), unless you have enabled the JSON-P Container 2.1 feature (jsonpContainer-2.1) in order to provide a third-party implementation of JSON-P.

You can find out more about this specific update and the wider technology with the following links:

Support for build compatible extensions and observable container state events (CDI 4.0)

CDI allows objects to be bound to lifecycle contexts, to be injected, to be associated with interceptors and decorators, and to interact in a loosely coupled fashion by firing and observing events. Highlights of CDI 4.0 include support for build compatible extensions and observable container state events. This update also brings in new Jakarta EE 10 versions of the Jakarta Annotations and Jakarta Interceptors APIs.

Build compatible extensions

Previous versions of CDI allowed users to provide Portable Extensions to customize the CDI application initialization lifecycle. These Build Compatible Extensions make implementing extensions amenable to build-time processing. To implement a Build Compatible Extension, provide an implementation of the BuildCompatibleExtension interface, declared via META-INF/services. The implementation can provide methods annotated with one of the extension annotations, each of which corresponds to the extension execution phases:

@Discovery
@Enhancement
@Registration
@Synthesis
@Validation

For example, as part of the Enhancement phase, this implementation adds an additional MyQualifier annotation to the MyService type:

public class MyExtension implements BuildCompatibleExtension {
    @Enhancement(type=MyService.class)
    public void addMyQualifier(ClassConfig clazz) {
        clazz.addAnnotation(MyQualifier.class)
    }
}

Startup and Shutdown events

Two new observable container state events are now available: Startup and Shutdown. Applications can listen for these events to be notified when the CDI container is starting up and being shut down.

@ApplicationScoped
public class MyObserver {
    public void observeStartup(@Observes Startup startupEvent) { {
        System.out.println("CDI Container is starting");
    }

    public void observeShutdown(@Observes Shutdown shutdownEvent) { {
        System.out.println("CDI Container is stopping");
    }
}

You can control the order of multiple observer methods by using the @Priority annotation.

Empty beans.xml files

In previous versions of CDI, an empty beans.xml file indicated that an archive should be treated as an explicit bean archive (the equivalent of bean-discovery-mode="all"). In CDI 4.0, an empty beans.xml now causes an archive to be treated as an implicit bean archive (the equivalent of bean-discovery-mode="annotated"). If necessary, you can set the emptyBeansXmlCDI3Compatibility configuration option to enable compatibility with previous versions.

Unversioned beans.xml files

In previous versions of CDI, a non-empty beans.xml file that did not include a version attribute defaulted to bean-discovery-mode="all". In CDI 4.0, it defaults to bean-discovery-mode="annotated". However, you should properly version all beans.xml files, as shown in the following configuration example:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns="https://jakarta.ee/xml/ns/jakartaee"
    xsi:schemaLocation="https://jakarta.ee/xml/ns/jakartaee https://jakarta.ee/xml/ns/jakartaee/beans_4_0.xsd"
    version="4.0"
    bean-discovery-mode="annotated">
</beans>

Programmatic lookup of beans and instances

A new Handle API is now available to make programmatic inspection of Bean metadata easier. This avoids the need to create instances before they are actually required. You can obtain a Handle using the Instance API:

public interface Handle<T> extends AutoCloseable {
        T get();
        Bean<T> getBean();
        void destroy();
        void close();
}

Removed APIs

The following previously deprecated CDI APIs have been removed:

@New qualifier - replaced by @Dependent beans.
Bean#isNullable() - has not been used by the implementation since CDI 1.1.
BeanManager#fireEvent() - Use BeanManager.getEvent() instead.
BeanManager#createInjectionTarget(AnnotatedType) - replaced by BeanManager#getInjectionTargetFactory(AnnotatedType)
BeforeBeanDiscovery#addAnnotatedType(AnnotatedType) - replaced by BeforeBeanDiscovery#addAnnotatedType(AnnotatedType, String)

Configuration

The Liberty <cdi12> server.xml configuration element has been superseded by a new <cdi> element, which applies to CDI versions 1.2 and later. For example:

<cdi enableImplicitBeanArchives="false" emptyBeansXmlCDI3Compatibility="true"/>

The enableImplicitBeanArchives attribute is the same as it was in previous versions.
- If set to true, which is the default, then archives that do not contain a beans.xml file are treated as Implicit Bean Archives and scanned for classes that have bean defining annotations.
- If set to false, then archives that do not contain a beans.xml file are not scanned for annotated classes.
The emptyBeansXmlCDI3Compatibility attribute applies only to CDI 4.0.
- If set to true, then an archive that contains an empty beans.xml file is treated as an explicit bean archive, as it was in CDI 3.0 and earlier.
- If set to false, which is the default, then an archive that contains an empty beans.xml file is treated as an implicit bean archive. This is equivalent to setting bean-discovery-mode="annotated"..

To use the CDI 4.0 feature, add cdi-4.0 to your server.xml:

<featureManager>
  <feature>cdi-4.0</feature>
</featureManager>

Access any available annotations using getAnnotations() (Expression Language 5.0)

Jakarta EE 10 Expression Language 5.0 includes a number of new features, deprecations, and specification clarifications. One of the new features is the addition of the MethodReference, a new class that allows developers to access any annotations present on a particular method using the getAnnotations() method.

To enable Expression Language 5.0, add the expressionLanguage-5.0 feature to the list of features in your server.xml file:

<featureManager>
  <feature>expressionLanguage-5.0</feature>
</featureManager>

More information about Expression Language 5.0 can be found in:

Enhanced parallel and reactive programming models available to applications (Concurrency 3.0)

The Jakarta Concurrency specification enhances the set of parallel and reactive programming models available to applications, enabling tasks and completion stage actions to run with the thread context of the submitter.

Concurrency 3.0 includes the following enhancements:

Resource definition annotations that put applications in control of defining the concurrency constraints and thread context types that the application requires
Context-aware completion stages that are managed by the container
Asynchronous methods that are backed by context-aware completion stages
Improvements to Triggers for customizing the scheduling of business logic according to dates and times within one’s own time zone
Standardized integration for third-party providers of thread context

Enable the concurrent-3.0 feature in server.xml, along with other Jakarta EE 10 beta features that you wish to use in combination with it, for example:

<featureManager>
  <feature>concurrent-3.0</feature>
  <!-- other features that are used in the examples: -->
  <feature>cdi-4.0</feature>
  <feature>jdbc-4.2</feature>
  <feature>jndi-1.0</feature>
  <feature>restfulWS-3.1</feature>
</featureManager>

You can still configure <managedExecutorService> and other Concurrency resource types in your server.xml file as you did for previous versions of the feature. However, In Concurrency 3.0 you can define those resources within application components. With the CDI feature enabled, methods that return a CompletionStage or CompletableFuture can be designated to run asynchronously by annotating them with @Asynchronous. For example:

import jakarta.enterprise.concurrent.Asynchronous;
import jakarta.inject.Singleton;

import java.sql.*;
import java.util.concurrent.CompletableFuture;
import java.util.concurrent.CompletionException;

import javax.naming.InitialContext;
import javax.naming.NamingException;
import javax.sql.DataSource;

@Singleton
public class AccountsBean {

    @Asynchronous(executor = "java:module/concurrent/MyExecutor")
    CompletableFuture<List<Account>> findOverdue(int minDaysLate) {
        List<Account> overdueAccounts = new ArrayList<Account>();
        try {
            // Resource reference lookup requires context of the application component,
            DataSource db = InitialContext.doLookup("java:comp/env/jdbc/account-db-ref");
            ...
            return Asynchronous.Result.complete(overdueAccounts);
        } catch (NamingException | SQLException x) {
            throw new CompletionException(x);
        }
    }

    ...

When the application invokes the asynchronous method, the container intercepts the invocation and hands back a completion stage representing its eventual completion, which is arranged by the ManagedExecutorService. For example:

    @GET
    public Response remindAboutOverdueAccounts () {
        ...
        accounts.findOverdue(60).thenAccept(this::sendReminder);
        ...
    }

    void sendReminder(List<Account> overdue) {
        try {
            // Resource reference lookup requires context of the application component,
            DataSource db = InitialContext.doLookup("java:comp/env/jdbc/customer-db-ref");
            ...
        } catch (NamingException | SQLException x) {
            throw new CompletionException(x);
        }
    }

The Maven coordinates for Concurrency 3.0 are as follows:

<dependency>
    <groupId>jakarta.enterprise.concurrent</groupId>
    <artifactId>jakarta.enterprise.concurrent-api</artifactId>
    <version>3.0.0</version>
</dependency>

For more resources regarding Concurrency 3.0, reference the following links:

Document APIs where authentication is optional or complex (MicroProfile OpenAPI 3.1)

The OpenAPI specification standardizes a way of documenting REST APIs in a JSON or YAML format. The MicroProfile OpenAPI specification helps you generate and serve OpenAPI documentation for your REST applications that are built by using JAX-RS or Jakarta RESTful Web Services. This can be useful for developers to test out the API during development, or for people using the API in production.

MicroProfile OpenAPI 3.1 is a minor release that includes the following updates:

Some Jakarta Bean Validation annotations will now be read and their restrictions will be added to object schemas.
Most annotations now include an extension attribute.
@SecurityRequirementsSet can now be used to document operations where authentication is optional or where more than one authentication mechanism is required.

To use MicroProfile OpenAPI 3.1, add the mpOpenAPI-3.1 feature to your server.xml:

<featureManager>
    <feature>mpOpenAPI-3.1</feature>
</featureManager>

Next, deploy your rest application and then visit the /openapi endpoint to view the OpenAPI documentation, or visit /openapi/ui for a user interface where you can browse through it. You can enhance the documentation by using annotations to add things like textual descriptions to each method. The annotations are available as a Maven dependency:

<dependency>
    <groupId>org.eclipse.microprofile.openapi</groupId>
    <artifactId>microprofile-openapi-api</artifactId>
    <version>3.1-RC2</version>
</dependency>

For more information about MicroProfile OpenAPI, see the following links:

Stand-alone user registries no longer forcefully federated (Password Utilities 1.1)

The new passwordUtilities-1.1 feature no longer starts the federatedRegistry-1.0 feature or the Jakarta Connectors feature. Stand-alone user registries are no longer forcefully federated, which sometimes results in slightly different behavior.

To enable Password Utilities 1.1, add the passwordUtilities-1.1 feature to the list of features in your server.xml file:

<featureManager>
    <feature>passwordUtilities-1.1</feature>
</featureManager>

For more information about the Password Utilities, check out the feature documentation.

Try it now

To try out these features, just update your build tools to pull the Open Liberty All Beta Features package instead of the main release. The beta works with Java SE 18, Java SE 17, Java SE 11, and Java SE 8, however, the Jakarta EE 10 features are only compatible with Java SE 11 and later.

If you’re using Maven, here are the coordinates:

<dependency>
  <groupId>io.openliberty.beta</groupId>
  <artifactId>openliberty-runtime</artifactId>
  <version>22.0.0.9-beta</version>
  <type>pom</type>
</dependency>

Or for Gradle:

dependencies {
    libertyRuntime group: 'io.openliberty.beta', name: 'openliberty-runtime', version: '[22.0.0.9-beta ,)'
}

Or take a look at our Downloads page.

We welcome your feedback

Let us know what you think on our mailing list. If you hit a problem, post a question on StackOverflow. If you hit a bug, please raise an issue.

View stack trace separately from messages in logged exceptions and time-based log rollover in Open Liberty 22.0.0.8

Tue, 02 Aug 2022 00:00:00 +0000

Open Liberty 22.0.0.8 provides a new capability to view stack trace separately from messages in logged exceptions with new fields for Open Liberty JSON logging and for the Logstash Collector feature. This capability enables easier-to-read visualizations in downstream log analysis tools. Also new in this release is time-based log rollover, which enables you to specify a time of day for log files to roll over. This release also includes an important security vulnerability (CVE) fix, as well as many notable bug fixes.

In Open Liberty 22.0.0.8:

View stack trace separately from logged messages in logging records
Time-based log rollover for Liberty
jaxws-2.2 updates to CXF 3.4
Security Vulnerability (CVE) Fixes
Notable bug fixes

View the list of fixed bugs in 22.0.0.8.

Run your apps using 22.0.0.8

If you’re using Maven, here are the coordinates:

<dependency>
    <groupId>io.openliberty</groupId>
    <artifactId>openliberty-runtime</artifactId>
    <version>22.0.0.8</version>
    <type>zip</type>
</dependency>

Or for Gradle:

dependencies {
    libertyRuntime group: 'io.openliberty', name: 'openliberty-runtime', version: '[22.0.0.8,)'
}

Or if you’re using Docker:

FROM open-liberty

Or take a look at our Downloads page.

View stack trace separately from logged messages in logging records

The stack trace is now separated from logged messages in logging records so that log analysis tools can present them more clearly. This makes visualizations of the logs by downstream log analysis tools easier to read when you are identifying any issues encountered by the application. Previously, any logging record originating from a Java Logger object that made use of any of the methods that accept a Throwable parameter would simply append the stack trace to the existing message field. Keeping the message field solely for the logged message and having a separate field for the stack trace and exception type enhances the effectiveness of downstream log analysis tools.

Java’s Logging API provides methods that allow you to include a Throwable as a parameter. When the Throwable object is used, Open Liberty’s JSON logging provides two new fields, ibm_stackTrace and ibm_exceptionName, and the Open Liberty Logstash Collector feature provides two new fields, stackTrace and exceptionName. The stack trace fields present only the stack trace of the Throwable object. The exception name fields present the type of exception of the Throwable object.

Example:

For the example, we will only show the message log record for Open Liberty’s JSON logging.

Application with the following code snippet:

Logger logger = Logger.getLogger(MyResource.class.getCanonicalName());
Exception exception = new IllegalArgumentException("ouch");
logger.log(Level.INFO, "exception message", exception);

Previous Open Liberty JSON logging output:

{
    "type": "liberty_message",
    ...
    "message": “exception message  java.lang.RuntimeException: ouch\r\n\tatmy.package.MyResource.get(MyResource.java:32)\r\n\tatmy.package.MyResource.get(MyResource.java:20)\r\n...",
    ...
}

New Open Liberty JSON logging output:

{
    "type": "liberty_message",
    ...
    "message": “exception message",
    "ibm_exceptionName":"java.lang.IllegalArgumentException",
    "ibm_stackTrace":"java.lang.IllegalArgumentException: ouch\r\n\tat my.package.MyResource.get(MyResource.java:20)\r\n...",
    ...
}

Time-based log rollover for Liberty

Liberty provides a few different log files; a message.log is created by default, and a trace.log and http_access.log can be enabled for tracing and NCSA access logs respectively. Previously, these log files could be rolled over only by either server restart or by limiting the maximum log file size with the maxFileSize logging attribute. Instead of file size-based log rollover, users may want to roll over their files at periodic times to facilitate their existing log cleaning or archival processes.

Now, you can enable time-based periodic rollover of those log files at their own specified time of day by using two new optional logging configuration attributes: rolloverInterval and rolloverStartTime. Upon roll over, the file names are appended with a timestamp that corresponds to the time that the log was rolled over.

rolloverInterval is the desired time interval between log rollovers. Set the attribute with a positive integer followed by a unit of time, which can be days (d), hours (h), or minutes (m). For example, specify 5 hours as 5h. You can include multiple values in a single entry. For example, 1d5h is equivalent to 1 day and 5 hours.
rolloverStartTime is the time of day when logs first roll over and the first rollover interval duration begins. Valid values for this attribute follow a 24-hour ISO-8601 time format of HH:MM, where 00:00 represents midnight.

The two configuration attributes are optional. If neither of the attributes are set, then time-based log rollover is not enabled. If only one of the two attributes is set, then time-based log rollover is enabled, and the other attribute is set to its default. The default value for rolloverInterval is 1d, and the default value for rolloverStartTime is 00:00.

Example server.xml file configuration for log rollover in the messages.log and trace.log files by specifying the new attributes in the logging element:

<server>
   ...
    <logging rolloverStartTime="00:00" rolloverInterval="1d"/>
    ...
</server>

Example server.xml file configuration for log rollover in the http_access.log file by specifying the new attributes in the httpAccessLogging element:

<server>
   ...
    <httpAccessLogging rolloverStartTime="00:00" rolloverInterval="1d" logFormat='%h %u %{t}W "%r" %s %b' />
    ...
</server>

Example server.xml configuration for access logging, using <accessLogging/> under <httpEndpoint/>, which handles http_access.log rollover:

<server>
   ...
   <httpEndpoint id="defaultHttpEndpoint">
      <accessLogging rolloverStartTime="00:00" rolloverInterval="1d" logFormat='%h %i %u %t "%r" %s %b' />
   </httpEndpoint>
    ...
</server>

Example result of logs, rolled over every minute, with a configuration of rolloverInterval="1m" and rolloverStartTime="00:00":

For more information about this feature, refer to the HTTP Access Logging, Liberty Logging, and Liberty Access Logging documentation.

jaxws-2.2 updates to CXF 3.4

We’ve updated jaxws-2.2 to use CXF 3.4, which is a major update coming all way up from CXF 2.6.2. Anyone using jaxws-2.2 will automatically get the update with 22.0.0.8, but don’t worry, Liberty’s zero migration means we’ve taken great care to prevent any behavior changes. The main reason for us to make this change is to make jaxws-2.2 easier to maintain and keep up-to-date going forward. We expect this to result in quicker turn around time on pulling in the latest fixes from CXF and it’s related dependencies going forward and a slightly smaller runtime footprint as well!

Security vulnerability (CVE) fixes in this release

CVE	CVSS Score	Vulnerability Assessment	Versions Affected	Notes
CVE-2022-22476	5	Identity spoofing	17.0.0.3 - 22.0.0.7	Affects the App Security 1.0, App Security 2.0, App Security 3.0 and App Security 4.0 features

CVE

CVSS Score

Vulnerability Assessment

Versions Affected

Notes

CVE-2022-22476

Identity spoofing

17.0.0.3 - 22.0.0.7

Affects the App Security 1.0, App Security 2.0, App Security 3.0 and App Security 4.0 features

For a list of past security vulnerability fixes, reference the Security vulnerability (CVE) list.

Notable bugs fixed in this release

We’ve spent some time fixing bugs. The following sections describe just some of the issues resolved in this release. If you’re interested, here’s the full list of bugs fixed in 22.0.0.8.

UI generated by openapi-3.1 feature doesn’t show the link specific endpoints

An issue arose that when you clicked an endpoint in the UI that is generated by the openapi-3.1 feature, the clicked endpoint is expanded but the URL of the browser is not changed. As the result, you could not pass a link to a specific endpoint to others for reference. The URL of the browser is expected to change to show the link to the clicked endpoint.

This issue has since been reviewed and subsequently the affected features list have been updated once the UI is shared with the mpOpenApi features. This did previously work for openapi-3.1 but had been broken by #19535 in 22.0.0.2. This issue has now been resolved.
Server start fails when directory has spaces

On Windows operating system, when the server working directory is specified using the SERVER_WORKING_DIR environment variable and a space is present in the name of the server working directory, an attempt to start the server using the server script will hang and the server will not start.

This issue was due to missing quotes in the server script and has since been resolved. You can find out more information about this fix of adding quotes to server working directory test here.
Port MYFACES-4432 to JSF 2.3 and Faces 3.0 (Resolve request object in facelets)

The issue occurred when using the "@FacesConfig" annotation in a JSF 2.3 or Faces 3.0 application, the #{request} object fails to resolve. An empty string is returned instead.

This issue has now been closed as completed in #21599
EJB persistent timers that were deferred during app start do not run when app finishes starting

EJB Persistent Timers that get deferred due to the application not being started yet do not run after the application finishes starting.

Steps to reproduce are to have a large, slowly-starting application with a number of persistent EJB timers around from a previous run. Start the server and if timing is right, the timers will never start running.

The expected behavior is for EJB persistent timers that were deferred due to an unavailable application should run after the application becomes available again.

This issue has been resolved by running deferred tasks after the app starts in #21616.

featureUpdate downloads fail in Windows, due to #20945

The issue is caused by the inability to connect to Maven repo on Windows due to changes made in #20945. There is a need to append a forward slash (/) instead of File.separator for urls.

Running featureUtility.exe installFeature or`featureUtility.exe installServerFeature` causes the following:

The remote repository "https://repo.maven.apache.org/maven2/\" is missing the following artifacts: [json-1.0-22.0.0.7.pom, json-1.0-22.0.0.7.esa]
[7/27/22, 11:31:52:318 PDT] Downloading required features ...
[7/27/22, 11:31:52:334 PDT] Starting installation ...
[7/27/22, 11:31:52:365 PDT] Successfully completed cleaning up temporary files.
<---------------------> Infinity%
java.lang.NullPointerException
at com.ibm.ws.install.featureUtility.FeatureUtility.installFeatures(FeatureUtility.java:483)
at com.ibm.ws.install.featureUtility.cli.InstallFeatureAction.install(InstallFeatureAction.java:241)
at com.ibm.ws.install.featureUtility.cli.InstallFeatureAction.execute(InstallFeatureAction.java:257)
at com.ibm.ws.install.featureUtility.cli.InstallFeatureAction.handleTask(InstallFeatureAction.java:78)
at com.ibm.ws.install.featureUtility.cli.FeatureAction.handleTask(FeatureAction.java:100)
at com.ibm.ws.install.featureUtility.FeatureUtilityExecutor.main(FeatureUtilityExecutor.java:58)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at com.ibm.ws.kernel.boot.cmdline.UtilityMain.internal_main(UtilityMain.java:173)
at com.ibm.ws.kernel.boot.cmdline.UtilityMain.main(UtilityMain.java:53)
at com.ibm.ws.kernel.boot.cmdline.Main.main(Main.java:52)

This issue has since been resolved by #21667 which reverts the File.separator to a forward slash and the features now install successfully.

Get Open Liberty 22.0.0.8 now

Available through Maven, Gradle, Docker, and as a downloadable archive.

Use Jakarta EE 9.1 dependencies with MicroProfile GraphQL 2.0 in Open Liberty 22.0.0.6

Tue, 07 Jun 2022 00:00:00 +0000

Open Liberty 22.0.0.6 offers MicroProfile GraphQL 2.0, which incorporates Jakarta EE 9.1 dependencies, allowing the use of updated Jakarta components such as CDI 3.0, Jakarta REST 3.0, JSON-B 2.0 and more. An enhancement to JPA 2.1 provides improved Db2 query performance by altering parameter binding behavior. This release also contains a number of significant bug fixes as well as important security vulnerability (CVE) fixes.

In Open Liberty 22.0.0.6:

Use Jakarta EE 9.1 dependencies with MicroProfile GraphQL 2.0
Improved Db2 query performance
Security Vulnerability (CVE) Fixes
Notable bug fixes

View the list of fixed bugs in 22.0.0.6.

Run your apps using 22.0.0.6

If you’re using Maven, here are the coordinates:

<dependency>
    <groupId>io.openliberty</groupId>
    <artifactId>openliberty-runtime</artifactId>
    <version>22.0.0.6</version>
    <type>zip</type>
</dependency>

Or for Gradle:

dependencies {
    libertyRuntime group: 'io.openliberty', name: 'openliberty-runtime', version: '[22.0.0.6,)'
}

Or if you’re using Docker:

FROM open-liberty

Or take a look at our Downloads page.

Use Jakarta EE 9.1 dependencies with MicroProfile GraphQL 2.0

GraphQL is an open source data query and manipulation language for APIs and a runtime that fulfills queries with existing data. You can use a GraphQL service to obtain data from multiple sources (such as APIs, databases, and other services) by making only a single request. The GraphQL service can then collate this data into a single object, which simplifies the data retrieval. This results in faster application load times and lower data transfer costs. GraphQL enables clients to better customize requests to the server. Many enterprise companies use GraphQL, including Atlassian, Coursera, Facebook, GitHub, PayPal, and Twitter.

You can implement GraphQL support for applications that run on Open Liberty by enabling the MicroProfile GraphQL feature. When this feature is enabled, you can define GraphQL endpoints by using annotations, similar to how you create RESTful Web Services (formerly JAX-RS) resources.

MicroProfile GraphQL 2.0 incorporates Jakarta EE 9.1 dependencies. If you have been using MicroProfile GraphQL 1.0 in your application running on Open Liberty, you can continue to do so but with the updated Jakarta features such as CDI 3.0, restfulWS 3.0, JSON-B 2.0, etc. Functionally, version 2.0 behaves the same as 1.0 because it uses the same version of the underlying implementation (SmallRye GraphQL).

If you’d like to learn more about MicroProfile GraphQL:

Try it out with our Optimizing REST queries for microservices with GraphQL guide (available in the cloud or as downloads to your laptop).
See our Build GraphQL applications with MicroProfile GraphQL docs.
See our blog post on how to use the GraphiQL UI and third-party Client APIs.

To enable the MicroProfile GraphQL 2.0 feature, add it to your server.xml:

<featureManager>
  <feature>mpGraphQL-2.0</feature>
</featureManager>

Improved Db2 query performance

This new JPA enhancement improves EclipseLink’s Db2 and Db2 z/OS support by enabling parameter binding for JPA specification-defined functions.

For Db2 and Db2 for z/OS, EclipseLink’s JPQL parameter binding is disabled when function expressions (SQRT, ABS, SUBSTR, COALESCE, etc.) exist within a JPQL query. This update allows EclipseLink to bind JPQL parameters for function expressions that accept untyped parameter markers on Db2 and Db2 z/OS. This update also allows EclipseLink to enable and disable parameter binding per expression within a query, rather than for the entirety of the query.

For Db2 and Db2 for z/OS, EclipseLink does not bind JPQL literal values as SQL parameter values. The "shouldBindLiterals=true" EclipseLink-specific persistence property allows EclipseLink users to bind all literal values as parameter values. However, this property is currently ignored by EclipseLink for Db2 and Db2 for z/OS. This enhancement allows you to use the "shouldBindLiterals=true" EclipseLink persistence property to bind literals values as parameters on Db2 and Db2 z/OS; assuming this binding is legal according to the database.

Enabling parameter binding

To start using the new function, add the new eclipselink.jdbc.allow-partial-bind-parameters persistence property to your persistence.xml properties:

<persistence ... >
    <persistence-unit ... >
        <properties>
            <property name="eclipselink.jdbc.allow-partial-bind-parameters" value="true"/>
        </properties>
     </persistence-unit>
</persistence>

Alternatively, in Liberty 22.0.0.2 and later, you can add the new <defaultProperties> configuration to the <jpa> configuration in your server.xml file. This applies the eclipselink.jdbc.allow-partial-bind-parameters persistence property to all persistence units within applications that run on this server. For example:

<server>
    <featureManager>
        <feature>jpa-2.1</feature>
    </featureManager>
    ...
    <jpa>
        <defaultProperties>
            <property name="eclipselink.jdbc.allow-partial-bind-parameters" value="true"/>
        </defaultProperties>
    </jpa>
</server>

Using parameter binding

In the application, you can take advantage of this feature with JPA JPQL queries and CriteriaBuilder API queries.

Example 1:

    Query query = em.createQuery("SELECT g FROM Guest g WHERE LENGTH(?1) > 2 AND g.lastName = TRIM(?1)");
    query.setParameter(1, "Crusher");

By default, EclipseLink generates the following SQL prepared statement on Db2 and Db2 z/OS:

    SELECT FIRSTNAME, LASTNAME FROM GUEST WHERE ((LENGTH('Crusher') > 2) AND (LASTNAME = TRIM('Crusher')))

With the new property eclipselink.jdbc.allow-partial-bind-parameters = "true", EclipseLink generates the following SQL prepared statement on Db2:

    SELECT FIRSTNAME, LASTNAME FROM GUEST WHERE ((LENGTH('Crusher') > 2) AND (LASTNAME = TRIM(?)))

and DB2 z/OS:

    SELECT FIRSTNAME, LASTNAME FROM GUEST WHERE ((LENGTH('Crusher') > 2) AND (LASTNAME = TRIM('Crusher')))

Even though the property is enabled, no change is apparent for Db2 z/OS, because using an untyped parameter marker in the LENGTH or TRIM functions is illegal on Db2 z/OS. However, many other functions exist where it is legal to use parameter markers on Db2 z/OS. This example was chosen to show the differences between the Db2 and Db2 z/OS platforms. When the property is enabled, EclipseLink knows what is legal on what platform.

Example 2:

    Query query = em.createQuery("SELECT g FROM Guest g WHERE LENGTH(?1) > 2 AND g.lastName = TRIM(?1)");
    query.setParameter(1, "Crusher");

By default, EclipseLink generates the following SQL prepared statement on Db2 and Db2 z/OS:

    SELECT FIRSTNAME, LASTNAME FROM GUEST WHERE ((LENGTH('Crusher') > 2) AND (LASTNAME = TRIM('Crusher')))

With the new property eclipselink.jdbc.allow-partial-bind-parameters = "true", EclipseLink generates the following SQL prepared statement on Db2:

    SELECT FIRSTNAME, LASTNAME FROM GUEST WHERE ((LENGTH('Crusher') > 2) AND (LASTNAME = TRIM(?)))

and Db2 z/OS:

    SELECT FIRSTNAME, LASTNAME FROM GUEST WHERE ((LENGTH('Crusher') > 2) AND (LASTNAME = TRIM('Crusher')))

However, with the addition of an existing EclipseLink property

    <property name="eclipselink.target-database-properties" value="shouldBindLiterals=true"/>

EclipseLink generates the following SQL prepared statement on Db2:

    SELECT FIRSTNAME, LASTNAME FROM GUEST WHERE ((LENGTH('Crusher') > ?) AND (LASTNAME = TRIM(?)))

and Db2 z/OS:

    SELECT FIRSTNAME, LASTNAME FROM GUEST WHERE ((LENGTH('Crusher') > ?) AND (LASTNAME = TRIM('Crusher')))

Notice that with the addition of the shouldBindLiterals property, the literal value 2 is bound as a parameter in the SQL string. Without the feature enabled, EclipseLink cannot enable binding for some parts of the query and instead only enables or disables for the whole query. As we can see in this example, EclipseLink can enable some parameter binding while also respecting what is legal or illegal on Db2 and Db2 z/OS.

Security vulnerability (CVE) fixes in this release

CVE	CVSS Score	Vulnerability Assessment	Versions Affected	Notes
CVE-2022-22475	5	Identity spoofing	17.0.0.3 - 22.0.0.5	Affects the App Security 1.0, App Security 2.0, App Security 3.0 and App Security 4.0 features
CVE-2022-22393	3.1	Information disclosure	17.0.0.3 - 22.0.0.5	Affects the Admin Center 1.0 feature

For a list of past security vulnerability fixes, reference the Security vulnerability (CVE) list.

Notable bugs fixed in this release

We’ve spent some time fixing bugs. The following sections describe just some of the issues resolved in this release. If you’re interested, here’s the full list of bugs fixed in 22.0.0.6.

Liberty OIDC error is being returned with incorrect characters

Previously, Liberty’s OIDC error was returned with incorrect characters. When invoking the OP’s /authorize endpoint with missing or incorrect parameters in traditional Chinese, the returned error message had a number of ???? instead of Chinese characters. The same happened for other non-ascii languages.

The error page showed:
```
"Accept-Language: zh-TW"
HTTP/1.1 200 OK
X-Powered-By: Servlet/3.0
Content-Language: en-DE
Transfer-Encoding: chunked
Date: Fri, 06 May 2022 08:42:36 GMT

CWOAU0033E: ????????????client_id
```
This issue has now been fixed and the page should contain the properly translated error message instead of ????????????.
Refresh token is not cleaned up when a JWT access_token had been issued

The refresh_token cleanup for an OIDC end_session instance is different depending on the type of access_token issued. The Liberty OP can issue opaque or JWT access_tokens. When running end_session, the refresh_token is removed from the cache when creating opaque access_tokens, however when creating JWT access_tokens, the refresh_token was NOT removed. This issue has been resolved and running end_session on providers that generate JWT access_tokens should invalidate the refresh_token.
Custom claims not passed to the back end

When using MicroProfile Starter start.microprofile.io to generate service-a and service-b running on Open Liberty, the invocation to the service b no longer sent out the custom claim on invoking the JWT backend via localhost:9080. This defect was caused by the changes which exposed a hidden problem in the Claims.putAll method when there were claims with a null value and has since been fixed.
Bump netty dependencies to 4.1.77.Final

Netty components in Open Liberty were of the version 4.1.75.Final released in March 2022. The latest version 4.1.77.Final contains various bug fixes and improvements over the current version. These components have been updated to ensure that Open Liberty stays up to date with upstream fixes and improvements.
Default session meta cache name failed with RH DataGrid

When Liberty created infinispan caches name with percent encoding, Datagrid Administration GUI Console failed to retrieve the cache name. An example would be:
```
com.ibm.ws.session.meta.default_host%2FGestionPedidos
```
Where GestionPedidos is the application web context, %2F is the encoded character for /. RH DataGrid failed to retrieve the above cache name.

Get Open Liberty 22.0.0.6 now

Available through Maven, Gradle, Docker, and as a downloadable archive.

Introducing a hands-on technical deep dive on Liberty

Fri, 03 Jun 2022 00:00:00 +0000

We are excited to announce the release of our newest tutorial, A Technical Deep Dive on Liberty.

A Technical Deep Dive on Liberty is an end-to-end tutorial that walks you through how to develop and deploy cloud-native Java applications in Jakarta EE and MicroProfile. The tutorial is aimed at Java developers, from Liberty novices to those more experienced with writing applications to run on Liberty.

In A Technical Deep Dive on Liberty, you will learn how to:

Build a RESTful microservice on Liberty with Jakarta EE and MicroProfile.
Easily document your REST API for developers to consume your microservice.
Externalize your configuration to make your application portable and easier to update.
Persist data to a database.
Secure your application using JSON Web Tokens (JWT) so that only authenticated and authorized applications can request information from your microservice.
Add health checks to easily report the statuses of your microservice (for orchestration decision).
Provide metrics to monitor activity and performance of your application.
Build a container image for your Java microservice.
Deploy the container image to Kubernetes using the Open Liberty Operator.
Test your applications easily with containers (for true-to-production testing).

If you don’t want to worry about local setup and prerequisites, try A Technical Deep Dive on Liberty in our cloud-hosted environment.

Alternatively, if you prefer, you can complete A Technical Deep Dive on Liberty on your own laptop.

We welcome your feedback

Tell us about your experience with A Technical Deep Dive on Liberty by responding to the questions in the Where to next? section at the end of the tutorial. We’d love to hear from you!

Learn MicroProfile 5.0 and Jakarta EE 9.1 from our newly enhanced cloud-hosted guides

Tue, 12 Apr 2022 00:00:00 +0000

To learn how to develop cloud-native Java applications and microservices on Open Liberty with MicroProfile 5.0 and Jakarta EE 9.1, you can try out our updated guides. You can run our guides in a hosted environment with enhanced interfaces, without having to worry about local setup and prerequisites. We recently updated 31 of our guides for compatibility with MicroProfile 5 and Jakarta EE 9. The Maven project pom.xml and Liberty configuration server.xml files in these guides are updated to use new Jakarta EE 9.1 and MicroProfile 5.0 APIs and features. Also, all Java classes now use the jakarta package namespace instead of javax, as shown in the following example.

To learn more about what changed in Jakarta EE 9.1, see the Jakarta EE 9.1 feature updates documentation. To learn about the differences between MicroProfile 5.0 and 4.1, see the Differences between MicroProfile 5.0 and 4.1 documentation.

What are the new enhancements in the cloud-hosted guides?

The cloud-hosted guides are enhanced with a new look and updated features. Whether or not you’ve tried them yet, now is the time to experience how easily you can learn to build applications with MicroProfile and Jakarta EE APIs.

You can access any of our updated MircoProfile or Jakarta EE cloud-hosted guides by clicking one of the links at the end of this post, or choose from our full collection of guides. After you choose a guide, click the Run in cloud button, as shown in the following image:

We’ve enhanced these guides to make them easier to navigate and to simplify running commands and managing files. The following screenshot shows the new look for our cloud-hosted guides. You can navigate to different sections of the guide by clicking the Table of Contents menu:

You can also navigate through the guide by clicking the blue progress bar after the Table of Contents menu:

Instead of copying and pasting the commands in terminal, you can now run the commands on an active terminal by simply clicking on the Execute >_ icon in the code window.

You can now directly open a file by clicking the Open … in IDE button, instead of browsing to it from the File > Open menu.

Also, you can launch an application simply by clicking the Visit… button. The application URL opens on a new browser tab.

Which guides are updated?

The following 31 guides are updated to use MicroProfile 5.0 and Jakarta EE 9.1 features:

We welcome your feedback

Tell us about your experience with our guides by responding to the questions in the Summary section at the end of each guide. We’d love to hear from you!

MicroProfile, Jakarta EE, and Open Liberty at DevNexus 2022

Mon, 04 Apr 2022 00:00:00 +0000

DevNexus, the longest-running and largest Java Conference in the USA will be happening this year in Atlanta, GA, from April 12-14. As in-person conferences make a comeback in 2022, this will be a great opportunity to re-connect with the Java community.

And of course, members of the Open Liberty team will be on-site hosting multiple sessions and running demonstrations and labs in the IBM booth. If you’re also going to be there, deciding which of the great talks to see can be a bit of a challenge. So we’ve put together a helpful summary of the sessions on MicroProfile, Jakarta EE and Open Liberty.

Talks at DevNexus 2022

A selection of Jakarta EE, MicroProfile, and Open Liberty talks on Wednesday and Thursday:

Wednesday 13th

Exploring Stateful Microservices in the Cloud Native World

Open Liberty’s Grace Jansen and Chicago JUG’s Mary Grygleski discuss how to handle persisting data with containerized microservices in a Cloud Native world.
Mother Nature vs Java - the security face off

Java Evangelist Steve Poole and Open Liberty’s Grace Jansen explore where software and biology overlap when it comes to security, and lessons we can learn from nature to improve our own application security.
Simple tweaks to get the most out of your JVM

Open Liberty’s Jamie Coleman will go through all the different JVM options and give you some easy and simple advice on how to get the most out of your JVM to save not only money but also energy on the cloud.
Landscape of MicroProfile and Jakarta EE Tools

Open Liberty’s YK Chang and Kathryn Kodama will examine the tools that are available to make your life easier as you code MicroProfile and Jakarta EE-based applications. These tools help developers throughout the development lifecycle, from creating a new application, working with compatible runtimes and your favourite editor, to testing your application.
Using byte-code analysis to modernize your Java EE applications

Open Liberty’s Cindy High will demonstrate how to analyze your Java EE applications using a simple command-line tool that will provide reports on your application structure and detailed analysis of potential issues when moving to a new Java SE or EE level or to cloud environments.

Thursday 14th

MicroProfile - The Current and The Future

Java Champion Emily Jiang is going to bring you up to date with the latest MicroProfile release and then briefly discuss the future road map for MicroProfile. Come along to listen in or ask questions.

Join us

All conference attendees are invited to join us at the IBM booth where you can check out our new Space Rover demo, challenge yourself with one or more Quick Labs, and get some great SWAG. IBMers will also be available at the Eclipse Foundation booth.

We’d love to see you at these key activities!

Jakarta EE Reception - Tuesday, April 12 @ 17:00 to 19:30 (room #412): Join the Jakarta EE community for some great discussions on the ever-changing landscape in enterprise Java and the future of cloud-native innovation that Jakarta EE represents, while enjoying drinks and snacks on IBM.
Book Signing - Wednesday, April 13 @ 15:20 (IBM Booth): Join IBMer, Java Champion, and co-author of a new eBook, “Practical cloud-native Java development with MicroProfile”, Emily Jiang as she signs and gives away copies of this popular publication.
Open Liberty Space Rover Challenge - Daily at the IBM Booth: Navigate the planets and get your rover safely to your destination in the stars. Take control of a spaceship and use hand signals to direct its flight from planet to planet. Climb the rankings on your way to become top cadet in Star Academy. Our Space Rover Challenge leverages a variety of technologies, including hardware, and modern Java technology. While you’re with us, ask our developers about the underlying technologies they’ve used to create the demo, including Open Liberty, also known as “the most flexible server runtime in the cosmos”, Jakarta EE, MicroProfile, and OpenJ9.

Check out IBM’s presence at DevNexus as well as the full schedule on the conference website.

Meet our open source champions: Emily Jiang

Wed, 23 Feb 2022 00:00:00 +0000

Concurrency 3.0 for Jakarta EE 10 in Open Liberty 22.0.0.3-beta

Thu, 17 Feb 2022 00:00:00 +0000

Although only a few short months have passed since we announced Jakarta EE 9.1 support in Open Liberty 21.0.0.12, we’re already implementing Jakarta EE 10 features. Concurrency 3.0 marks our first Jakarta EE 10 beta feature, available in Open Liberty 22.0.0.3-beta. Concurrency 3.0 introduces a variety of new enhancements including resource definition annotations that put applications in control of defining the concurrency constraints and thread context types that the application requires, context-aware completion stages that are managed by the container, and more.

All Beta Features package

The All Beta features package for Open Liberty contains all Open Liberty beta features and GA features and functions. This means that you can now try out our in-development Open Liberty features by just adding the relevant coordinates to your build tools. If you try the beta package, let us know what you think.

The All Beta Features package includes the following beta features:

Concurrency 3.0 for Jakarta EE 10

Concurrency 3.0 for Jakarta EE 10

Concurrency 3.0 includes the following enhancements:

Resource definition annotations that put applications in control of defining the concurrency constraints and thread context types that the application requires.
Context-aware completion stages that are managed by the container.
Asynchronous methods that are backed by context-aware completion stages.
Improvements to Triggers for customizing the scheduling of business logic according to dates and times within one’s own time zone.
Standardized integration for third-party providers of thread context.

While in beta, Open Liberty allows this Jakarta EE 10 feature to be used alongside Jakarta EE 9 features so that you can try it out with existing applications. Enable the concurrent-3.0 feature in your server.xml,

<featureManager>
    <feature>concurrent-3.0</feature>
</featureManager>

You can still configure <managedExecutorService> and other Concurrency resource types in server.xml as you did for previous versions of the feature.

However, Conurrency 3.0 gives you the ability to define those resources within application components:

import static jakarta.enterprise.concurrent.ContextServiceDefinition.ALL_REMAINING;
import static jakarta.enterprise.concurrent.ContextServiceDefinition.APPLICATION;
import static jakarta.enterprise.concurrent.ContextServiceDefinition.SECURITY;
import static jakarta.enterprise.concurrent.ContextServiceDefinition.TRANSACTION;

import jakarta.annotation.Resource;
import jakarta.enterprise.concurrent.ContextServiceDefinition;
import jakarta.enterprise.concurrent.ManagedExecutorDefinition;
import jakarta.enterprise.concurrent.ManagedExecutorService;
import jakarta.inject.Inject;
import jakarta.servlet.http.*;

import java.sql.*;
import java.util.concurrent.CompletionException;

@ContextServiceDefinition(name = "java:app/concurrent/AppContextOnly",
        propagated = APPLICATION,
        cleared = { TRANSACTION, SECURITY },
        unchanged = ALL_REMAINING)
@ManagedExecutorDefinition(name = "java:module/concurrent/MyExecutor",
        context = "java:app/concurrent/AppContextOnly",
        maxAsync = 5)
public class MyServlet extends HttpServlet {
    @Resource(name = "java:module/env/concurrent/MyExecutorRef",
              lookup = "java:module/concurrent/MyExecutor")
    ManagedExecutorService myExecutor;

    @Inject AccountsBean accounts;
    ...

With the CDI feature enabled, methods that return a CompletionStage or CompletableFuture can be designated to run asynchronously by annotating them with @Asynchronous.

import jakarta.enterprise.concurrent.Asynchronous;
import jakarta.inject.Singleton;

import java.sql.*;
import java.util.concurrent.CompletableFuture;
import java.util.concurrent.CompletionException;

import javax.naming.InitialContext;
import javax.naming.NamingException;
import javax.sql.DataSource;

@Singleton
public class AccountsBean {

    @Asynchronous(executor = "java:module/concurrent/MyExecutor")
    CompletableFuture<List<Account>> findOverdue(int minDaysLate) {
        List<Account> overdueAccounts = new ArrayList<Account>();
        try {
            // Resource reference lookup requires context of the application component,
            DataSource db = InitialContext.doLookup("java:comp/env/jdbc/account-db-ref");
            ...
            return Asynchronous.Result.complete(overdueAccounts);
        } catch (NamingException | SQLException x) {
            throw new CompletionException(x);
        }
    }

    ...

    public void doGet(HttpServletRequest req, HttpServletResponse res) {
        ...
        accounts.findOverdue(60).thenAccept(this::sendReminder);
        ...
    }

    void sendReminder(List<Account> overdue) {
        try {
            // Resource reference lookup requires context of the application component,
            DataSource db = InitialContext.doLookup("java:comp/env/jdbc/customer-db-ref");
            ...
        } catch (NamingException | SQLException x) {
            throw new CompletionException(x);
        }
    }

The Concurrency 3.0 specification hasn’t been published yet because Jakarta EE 10 is still under development. However, you can preview a draft of it at the concurrency-api GitHub page.

Similarly, the API jar will not be available on Maven until the specification is released, but in the meantime, you can check out the draft copy.

    <repositories>
        <repository>
            <id>ibmdhe</id>
            <name>IBM_DHE File Server</name>
            <url>https://public.dhe.ibm.com/ibmdl/export/pub/software/olrepo</url>
        </repository>
    </repositories>
    <dependencies>
        <dependency>
            <groupId>io.openliberty.jakarta.enterprise.concurrent</groupId>
            <artifactId>jakarta.enterprise.concurrent-api</artifactId>
            <version>3.0.0.20220120</version>
        </dependency>
    <dependencies>

Try it now

To try out these features, just update your build tools to pull the Open Liberty All Beta Features package instead of the main release. The beta works with Java SE 17, Java SE 11, or Java SE 8.

If you’re using Maven, here are the coordinates:

<dependency>
  <groupId>io.openliberty.beta</groupId>
  <artifactId>openliberty-runtime</artifactId>
  <version>22.0.0.3-beta</version>
  <type>pom</type>
</dependency>

Or for Gradle:

dependencies {
    libertyRuntime group: 'io.openliberty.beta', name: 'openliberty-runtime', version: '[22.0.0.3-beta,)'
}

Or take a look at our Downloads page.

Your feedback is welcomed

Let us know what you think on our mailing list. If you hit a problem, post a question on StackOverflow. If you hit a bug, please raise an issue.

Enhancements to JPA persistence properties and a number of significant bug fixes in Open Liberty 22.0.0.2

Tue, 15 Feb 2022 00:00:00 +0000

Open Liberty 22.0.0.2 adds the ability to declare default JPA persistence properties to all container-managed persistence contexts as part of the Liberty configuration. This release also provides a number of significant bug fixes.

In Open Liberty 22.0.0.2:

Define JPA persistence properties at server scope

View the list of fixed bugs in 22.0.0.2.

Run your apps using 22.0.0.2

If you’re using Maven, here are the coordinates:

<dependency>
    <groupId>io.openliberty</groupId>
    <artifactId>openliberty-runtime</artifactId>
    <version>22.0.0.2</version>
    <type>zip</type>
</dependency>

Or for Gradle:

dependencies {
    libertyRuntime group: 'io.openliberty', name: 'openliberty-runtime', version: '[22.0.0.2,)'
}

Or if you’re using Docker:

FROM open-liberty

Or take a look at our Downloads page.

Define JPA persistence properties at server scope

This new JPA enhancement adds the ability to declare default JPA persistence properties to all container-managed persistence contexts as a Liberty server.xml configuration.

Previously, to set persistence property for all persistence.xml configuration files, you had to update each persistence.xml file in all applications. This could end up requiring hundreds of manual updates and/or rebuilding of applications. With this enhancement, you can specify persistence properties in the server.xml file that will propagate to all container-managed persistence units for all applications installed on that server.

To start using the new feature, add the new defaultProperties element to the jpa element configuration in your server.xml file. Use this element to specify the persistence properties that you want to apply to all container-managed persistence units:

Example 1:

<server>
    <featureManager>
        <feature>persistenceContainer-3.0</feature>
    </featureManager>

    <jpa defaultPersistenceProvider="org.hibernate.jpa.HibernatePersistenceProvider">
        <defaultProperties>
            <property name="javax.persistence.lock.timeout" value="4000"/>
            <property name="hibernate.dialect" value="org.hibernate.dialect.Oracle12cDialect"/>
        </defaultProperties>
    </jpa>
</server>

Example 2:

<server>
    <featureManager>
        <feature>jpa-2.1</feature>
    </featureManager>

    <jpa>
        <defaultProperties>
            <property name="javax.persistence.lock.timeout" value="12345"/>
            <property name="eclipselink.cache.shared.default" value="false"/>
        </defaultProperties>
    </jpa>
</server>

Technical description

These defaultProperties integration-level persistence properties will be supplied to the persistence provider specified when the PersistenceProvider.createContainerEntityManagerFactory method is called by the JPA Container.

According to the JPA specification (3.4.4.3):

If the same property or hint is specified more than once, the following order of overriding applies, in order of decreasing precedence:

* argument to method of EntityManager, Query, or TypedQuery interface
* specification to NamedQuery (annotation or XML)
* argument to createEntityManagerFactory method
* specification in persistence.xml

This means these new defaultProperties persistence property values will override any properties with the same name that are specified in a persistence.xml file. However, property values specified through PersistenceContext annotation, or the persistence-context-ref deployment descriptor element, or Query Hints property will override these defaultProperties.

For more information check out the GitHub issue for this feature.

Notable bugs fixed in this release

We’ve spent some time fixing bugs. The following sections describe just some of the issues resolved in this release. If you’re interested, here’s the full list of bugs fixed in 22.0.0.2.

OpenIdConnectClient cookies not getting deleted after logout

Previously, OpenID Connect nonce cookies could accumulate over multiple logins and not be cleared after logout. Instead, we would expect all cookies to be cleared after logout or on next login instead of accumulating. This issue was caused by not using the correct cookie name when clearing the nonce cookie and has now been fixed.

The output of ./wlp/bin/productInfo featureInfo missing new lines

In Open Liberty 22.0.0.1, the output of ./wlp/bin/productInfo featureInfo was missing new line characters. For example:

acmeCA-2.0adminCenter-1.0appClientSupport-1.0appSecurity-1.0appSecurity-2.0appSecurity-3.0appSecurityClient-1.0audit-1.0batch-1.0batchManagement-1.0beanValidation-1.1beanValidation-2.0bells-1.0cdi-1.2cdi-2.0cloudant-1.0concurrent-1.0constra ...

There are now line breaks between each of the feature names, as shown below:

acmeCA-2.0
adminCenter-1.0
appClientSupport-1.0
appSecurity-1.0
appSecurity-2.0
appSecurity-3.0
appSecurityClient-1.0
...

Updating MicroProfile versions on server.xml causes issues with install manager

Previously, updating to MicroProfile 5.0 in the server.xml and pom.xml would cause issues with the install manager. After resolving the features which are needed, the RepositoryResolver has to create lists of which features to install. There’s a list of everything needed for each requested feature and one for each auto-feature. When creating the install lists, it traversed the dependencies but stopped traversing when it founds a dependency which was installed. If distributedMap-1.0 is installed but distributedMapInternal-1.0 is not, it stops traversing dependencies when it hits distributedMap-1.0 and distributedMapInternal-1.0 is not added to the list. This bug was fixed by tracing down the entire dependency tree, building the list and finally removing any features which are already installed.
MP Fault Tolerance annotations at the class level of a Rest Client interface are ignored

A bug was discovered which led to MP Fault Tolerance annotations to be ignored when annotated at the class level of a Rest Client interface. However it would be picked up if annotated at method level. This issue was fixed by updating the rest client builder to check for fault tolerance annotations on the interface as well as on the method when deciding whether to add the @FaultTolerance annotation.
(JPA 2.2) EclipseLink: Deliver Bug #412391

JPA 2.2 has been updated to fix the EclipseLink bug #412391 - static weaving output failing silently on runtime when subclass entity has the same attribute as superclass entity.
"ERROR: Input redirection is not supported, exiting the process immediately" reported with Open Liberty as a service on Win

When running Open Liberty as a service on Windows, the following error was output when the timeout/retry logic was executed on start or stop:
```
ERROR: Input redirection is not supported, exiting the process immediately.
```
The expected behaviour would be for the server start script to loop the specified number of times, waiting for the server to start properly without echoing the ERROR message to the console. This issue has been fixed by updating the server.bat with ping command as opposed to timeout command. This behaviour should no longer occur.
NullPointerException in JSP after upgrade

A bug was introduced in 21.0.0.9 which caused apps to crash with a NullPointerException. This issue has now been fixed, as it was caused by a taglib referencing a tld file that didn’t exist.

Get Open Liberty 22.0.0.2 now

Available through Maven, Gradle, Docker, and as a downloadable archive.

MicroProfile 5.0, JWE support in OIDC and Social Media Login, and many more exciting new features in Open Liberty 22.0.0.1

Tue, 18 Jan 2022 00:00:00 +0000

Open Liberty 22.0.0.1 offers many exciting new features including MicroProfile 5.0, enabling applications to use MicroProfile APIs together with Jakarta EE 9.1. Other enhancements include MicroProfile RestClient’s implementation switching from Apache CXF to RESTEasy, MicroProfile OpenAPI receiving an update to support multiple applications, and JWE support being added to OpenID Connect Client and Social Media Login. Several other features and many bug fixes are also included in 22.0.0.1, as well as the introduction of signature files for our downloadable release binaries.

In Open Liberty 22.0.0.1:

MicroProfile 5.0
- MicroProfile Rest Client 3.0 - Switching to RESTEasy
Support multiple applications in mpOpenApi-2.0
Support JWE for OpenID Connect Client and Social Media Login
Block Loading of Classes with Known Vulnerabilities
Release packages are now signed
Using expansion variables in server.env
JVM Working Directory
Customizing Stale Connection Identification
Improvements to Deployment Descriptor Parsing

View the list of fixed bugs in 22.0.0.1.

Run your apps using 22.0.0.1

If you’re using Maven, here are the coordinates:

<dependency>
    <groupId>io.openliberty</groupId>
    <artifactId>openliberty-runtime</artifactId>
    <version>22.0.0.1</version>
    <type>zip</type>
</dependency>

Or for Gradle:

dependencies {
    libertyRuntime group: 'io.openliberty', name: 'openliberty-runtime', version: '[22.0.0.1,)'
}

Or if you’re using Docker:

FROM open-liberty

Or take a look at our Downloads page.

MicroProfile 5.0

MicroProfile 5.0 enables applications to use MicroProfile APIs together with Jakarta EE 9.1. MicroProfile 5.0, which includes Config 3.0, Fault Tolerance 4.0, Rest Client 3.0, Health 4.0, Metrics 4.0, Open Tracing 3.0, Open API 3.0, and JWT propagation 2.0, does not provide any other functional updates except aligning with the Jakarta namespace.

MicroProfile Rest Client 3.0 - Switching to RESTEasy

Although all features included in MicroProfile 5 received updates to make them compatible with Jakarta EE 9, Rest Client 3.0 deserves extra attention as its Open Liberty implementation is switching to RESTEasy (previously it used Apache CXF). This change brings with it some behavior and property changes (most of which are already documented as differences between jaxrs-2.1 and restfulWS-3.0).

Add the feature to the server.xml:

<server>
  <featureManager>
    <feature>microProfile-5.0</feature>
  </featureManager>
</server>

Support multiple applications in mpOpenApi-2.0

MicroProfile OpenAPI helps you document the REST endpoints of your application by creating and serving documentation in the OpenAPI format.

MicroProfile OpenAPI can now create OpenAPI documentation for more than one application. Previously, only the first deployed web module which included a JAX-RS application would be documented. When two or more web modules containing JAX-RS applications are deployed, the MicroProfile OpenAPI feature can now create documentation for each of them and then merge that documentation together.

To enable this functionality, you must set the MicroProfile Config property mp.openapi.extensions.liberty.merged.include=all, e.g. by adding this to your server.xml:

<variable name="mp.openapi.extensions.liberty.merged.include" value="all"/>

With this property set, deploy several JAX-RS applications and visit /openapi/ui on your Open Liberty server where you should see documentation for all the applications.

The following MP Config properties can be used to configure this feature:

Name Description Default Values

Name	Description	Default	Values
`mp.openapi.extensions.liberty.merged.include`	List of modules which should be included in the merged OpenAPI documentation	`first`	`all` (to include all applications) `first` (to include only the first web module deployed, matching the previous behavior) comma-separated list of `<appname>` (to include individual applications) and `<appname>/<modulename>` (to include individual modules within an EAR)
`mp.openapi.extensions.liberty.merged.exclude`	List of modules which should be excluded from the merged OpenAPI documentation Takes priority over the list of included modules	`none`	`none` (to exclude nothing) comma-separated list of <appname> (to exclude individual applications) and <appname>/<modulename> (to exclude individual modules within an EAR)
`mp.openapi.extensions.liberty.merged.info`	This property sets the info section of the final Open API document	N/A	The value must be a valid OpenAPI info section in JSON format. If this property is set, the info section in the final OpenAPI document is replaced with the value of the property. This replacement is made after any merging is completed.

mp.openapi.extensions.liberty.merged.include

List of modules which should be included in the merged OpenAPI documentation

first

all (to include all applications)
first (to include only the first web module deployed, matching the previous behavior)
comma-separated list of <appname> (to include individual applications) and <appname>/<modulename> (to include individual modules within an EAR)

mp.openapi.extensions.liberty.merged.exclude

List of modules which should be excluded from the merged OpenAPI documentation
Takes priority over the list of included modules

none

none (to exclude nothing)
comma-separated list of <appname> (to exclude individual applications) and <appname>/<modulename> (to exclude individual modules within an EAR)

mp.openapi.extensions.liberty.merged.info

This property sets the info section of the final Open API document

N/A

The value must be a valid OpenAPI info section in JSON format. If this property is set, the info section in the final OpenAPI document is replaced with the value of the property. This replacement is made after any merging is completed.

For more information, refer to the openAPI multi-module documentation.

Support JWE for OpenID Connect Client and Social Media Login

With this release, the OpenID Connect Client 1.0 and Social Media Login 1.0 features support receiving tokens in the JSON Web Encryption (JWE) format. A JWE is a way to represent encrypted content using JSON. In addition to supporting JWE, the OpenID Connect Client 1.0 feature provides an option to temporarily cache access token validation results for inbound propagation. Both features add support for the RS384, RS512, HS384, HS512, ES256, ES384, and ES512 signature algorithms.

Prior to this release, the OpenID Connect Client 1.0 and Social Media Login 1.0 features did not support consuming access or ID tokens in JWE format. This limited our interoperability with other OIDC clients and providers that use JWEs to propagate access tokens or provide identifying information about the authenticated user. With this release, the OpenID Connect Client 1.0 and Social Media Login 1.0 features will be able to interoperate with OpenID Connect Providers that provide JWE formatted access and ID tokens.

You can configure a Liberty OpenID Connect Relying Party to process access and ID tokens that are in a JWE format. The corresponding OpenID Connect Provider should support creating JWE access or ID tokens.

Set the OpenID Connect Provider with the OpenID Connect Relying Party’s public key that is used to encrypt the Content Encryption Key according to the OpenID Connect Provider’s documentation.
Set the keyManagementKeyAlias attribute to the private key alias of the key management key that is used to decrypt the Content Encryption Key of JWE token. The key must exist in the keyStore configured for the SSL configuration referred by the sslRef attribute. For example,
```
<openidConnectClient keyManagementKeyAlias="privateKeyAlias" />
```

Optional: Configure access token cache. You can configure a Liberty OpenID Connect Relying Party to cache access token validation results for inbound propagation.

Set the accessTokenCacheEnabled attribute to true.
Set the accessTokenCacheTimeout attribute to a duration specifying how long an authenticated subject that is created by using a propagated access token is cached.
Set the tokenReuse attribute to true if the OpenID Connect Relying Party must cache results for a JWT access token that includes a jti claim.

Although enabling this support may result in a performance improvement, it is recommended that the value for the accessTokenCacheTimeout attribute is short to reduce the possibility of a stale result as compared to what a validation call to the OpenID Connect Provider would have produced.

You can also configure Liberty OIDC Social Login to process ID tokens that are in a JWE format. The corresponding OpenID Connect Provider should support creating JWE ID tokens.

Set the OpenID Connect Provider with the OIDC Social Login’s public key that is used to encrypt the Content Encryption Key according to the OpenID Connect Provider’s documentation.
Set the keyManagementKeyAlias attribute to the private key alias of the key management key that is used to decrypt the Content Encryption Key of JWE token. The key must exist in the keyStore configured for the SSL configuration referred by the sslRef attribute. For example,
```
<oidcLogin keyManagementKeyAlias="privateKeyAlias" />
```

The signatureAlgorithm attributes of both elements now support the RS384, RS512, HS384, HS512, ES256, ES384, and ES512 signature algorithms.

<openidConnectClient signatureAlgorithm="RS384"/>
<oidcLogin signatureAlgorithm="RS384"/>

Block Loading of Classes with Known Vulnerabilities (e.g. Apache log4j "JndiLookup")

Applications deployed to Liberty may run versions of Log4j2 that are affected by Log4Shell (CVE-2021-44228) and related vulnerabilities.

This new function modifies the application and library class loaders to block the loading of the org.apache.logging.log4j.core.lookup.JndiLookup class, which is the cause of the vulnerability.

Users should analyze their applications for use of Log4j2 with urgency; in the meantime this functionality may help mitigate Log4Shell and other vulnerabilities related to the org.apache.logging.log4j.core.lookup.JndiLookup class. However, one should note that this will not protect in cases where the Log4j2 classes have been renamed (a process known as "shading") or if Log4j2 is loaded by other class loaders, such the Java system class loader or user-created class loaders.

Release packages are now signed

Starting in 22.0.0.1 release, we are signing our downloadable binaries. You can use these signature files and the corresponding public key to verify the authenticity and integrity of an Open Liberty release package.

The Open Liberty project uses its private key to digitally sign each Open Liberty release. You can use the Open Liberty public key to check the signature, verify that the package was released by Open Liberty, and that it was not modified since its release.

You can verify a release package either locally, by using the openssl command and a *.sig file, or on Maven Central, by using the gpg command.

Verifying Open Liberty packages with OpenSSL

To verify an Open Liberty release package locally, you must first download an Open Liberty .zip package, the corresponding .sig file, and the Open Liberty public key. You can then run the openssl command to verify the package.

Go to the Download package section of the Get Started page and download an Open Liberty .zip package and its corresponding .sig file.

Obtain the public key file by using the public key link on the Get Started page.

After you download the files, use the openssl command from the command line to verify the package. For example:

openssl dgst -sha256 -verify WebSphereLiberty_06-02-2021.pem -signature openliberty-javaee8-22.0.0.1.zip.sig openliberty-javaee8-22.0.0.1.zip

Verified OK

This example uses the WebSphereLiberty_06-02-2021.pem public key file and openliberty-javaee8-22.0.0.1.zip.sig signature file to verify the openliberty-javaee8-22.0.0.1.zip release package. Replace the signature file and package version values according to the package that you want to verify. If the verification is successful, the command produces the following console output.

Verify Liberty packages on Maven Central

To verify Open Liberty packages on Maven Central, you must first download the public key to your local machine by using the gpg or gpg2 command. You must edit the trust level for the key owner. You can then use this key to remotely verify an Open Liberty .asc release file on Maven Central.

Run the following command to download the public key file. The key ID value for the public key is 46102B8E.

gpg2 --keyserver hkp://keyserver.ubuntu.com --recv-keys 46102B8E

Use the gpg2 --edit-key command to set the trust for the key owner to 5. When you run the gpg2 --edit-key command, the console displays information about the key owner, followed by an internal command prompt. At this prompt, enter the trust command. You are then prompted to select a level of trust. Enter 5.

gpg2 --edit-key "WebSphere Liberty"
gpg> trust

Set trust 5

Verify the file by running the gpg2 --verify command. The following example verifies the Open Liberty 22.0.0.1 release package:

gpg2 --verify openliberty-runtime-22.0.0.1.zip.asc

gpg: assuming signed data in 'openliberty-runtime-22.0.0.1.zip'
gpg: Signature made Wed Nov 24 09:02:44 2021 EST
gpg: using RSA key 91FFD9A642D060B66B802B9D4D210F6946102B8E
gpg: Good signature from "WebSphere Liberty (Works for IBM) contbld@uk.ibm.com" [ultimate]
gpg: aka "WebSphereLiberty" [ultimate]

Using expansion variables in server.env

This update allows you to specify environment variables in the server.env file on Linux which are resolved when the server starts. This capability already exists on Windows.

Prior to this update, it might be necessary to provide custom packaged servers with hard-coded values in the server.env. Now server.env can consume these values from the system environment. On Windows this capability already existed, though it was not documented anywhere.

On Windows, this capability is enabled by default and has always existed. Since this is new to all other operating systems, it is necessary to enable the new capability by adding a comment line near the top of the file:

# enable_variable_expansion

Environment variables are specified using ${variable_name} syntax, except on Windows where the syntax is !variable_name! In the examples below the LOG_FILE variable is assigned the value of an environment variable. This example changes the name of the log file from the default name of console.log.

Example server.env on Windows:

keystore_password=XASEvZMKn3wG6XuTaVYFr8C
LOG_FILE=!CONSOLE_LOG!

Example server.env on Linux:

# enable_variable_expansion
keystore_password=XASEvZMKn3wG6XuTaVYFr8C
LOG_FILE=${CONSOLE_LOG}

For more information check out the Server configuration overview documentation.

JVM Working Directory

This enhancement introduces a new SERVER_WORKING_DIR environment variable which allows the user to set the JVM working directory location to something other than the ${WLP_OUTPUT_DIR}/serverName location. For portability purposes, the path supports not only absolute paths (one that contains a c:\ on Windows, or a / on linux based operating systems), but also allows users to specify relative paths to the ${WLP_OUTPUT_DIR}/serverName directory.

For example, the user could set the Open Liberty JVM output to be added to the ${WLP_OUTPUT_DIR}/serverName/logs location so that all JVM related data would be in with the server log data (relative path example) by setting the following:

SERVER_WORKING_DIR=logs

Or the user could move the information outside of the ${WLP_OUTPUT_DIR}/serverName location by doing something similar to the following (which would put the data in the /wlp/usr/servers/logs/ folder and is an absolute path example for Linux based operating systems):

SERVER_WORKING_DIR=/wlp/usr/servers/logs/

An absolute path example on Windows would look similar to the following:

SERVER_WORKING_DIR=c:\wlp\usr\servers\logs\

This enhancement gives users more flexibility regarding the location of the Open Liberty JVM output.

Customizing Stale Connection Identification

Open Liberty maintains a pool of JDBC connections to improve performance. It is necessary for Open Liberty to be able to identify when connections have become stale and are no longer usable so that such connections can be removed from the pool. Open Liberty leverages multiple standards made available by the JDBC and SQL specifications, as well as relying on some built-in knowledge of vendor-specific behavior for some JDBC drivers in order to achieve this.

Not all JDBC drivers completely follow the JDBC/SQL specifications in identifying stale connections. If you are using such a JDBC driver, it is now possible for you to provide additional configuration for a data source that helps identify the vendor-specific SQL states and error codes that are raised by the JDBC driver, enabling Liberty to better maintain the connection pool.

Configure one or more <identifyException> subelements under <dataSource> to provide the SQLException identification detail.

<featureManager>
  <feature>jdbc-4.2</feature>
  <feature>jndi-1.0</feature>
  ... other features
</featureManager>

<dataSource id="DefaultDataSource" jndiName="jdbc/myDataSource">
    <jdbcDriver libraryRef="myJDBCLib"/>
    <properties databaseName="TESTDB" serverName="localhost" portNumber="1234"/>
    <!-- identify the following as stale connections, -->
    <identifyException sqlState="08000" as="StaleConnection"/>
    <identifyException errorCode="2468" as="StaleConnection"/>
    <!-- remove built-in identification of SQL state S1000 -->
    <identifyException sqlState="S1000" as="None"/>
</dataSource>

<library id="myJDBCLib">
    <file name="C:/drivers/some-jdbc-driver.jar"/>
</library>

Improvements to Deployment Descriptor Parsing

This update updates the parsing of application deployment descriptor resources and updates the parsing of application bindings and extensions resources. These resources are XML format files which provide metadata for the application. Deployment descriptors are community defined, and include XML files application.xml, ejb-jar.xml, web.xml, application-client.xml and ra.xml. Bindings and extensions resources are in addition to the community defined resources, and are vendor specific. IBM defined bindings and extensions resources include ibm-application-bnd.xml, ibm-application-ext.xml, and several others. This update modifies the parsing of these XML resources in two ways. First, by relaxing rules relating to the header elements of the resources. The parsing rules were relaxed, allowing XML resources to have less header information than was previously required. Before the update, several header elements were required. After the update, only a version or a namespace-URI value are required. Second, this update improves the error messages which are displayed if there are problems parsing a resource. Error messages are now more specific, and contain more accurate information which describes where the errors occurred.

Notable bugs fixed in this release

We’ve spent some time fixing bugs. The following sections describe just some of the issues resolved in this release. If you’re interested, here’s the full list of bugs fixed in 22.0.0.1.

featureUtility installServerFeature fails when user feature is listed

featureUtility installServerFeatures previously contained bugs when the user configured a product extension in their server.xml, e.g.
```
<feature>myExt:userfeature-1.0</feature>
```
If the user feature file doesn’t contain the following regex (Liberty version), \\d\\d\\.\\d\\.\\d\\.\\d\\.esa, the user feature would not be installed to the defined product extension. The user feature doesn’t need to have the same version as the Liberty version. The tool didn’t fetch the installed features properly. Changes have been made to the underlying code to ensure that the feature name is extracted correctly from the filename.

ArrayIndexOutOfBoundsException during startup with mpOpenApi

During startup, mpOpenApi uses jandex to index classes and the following exception was observed:

java.lang.ArrayIndexOutOfBoundsException: Index 0 out of bounds for length 0
        at org.jboss.jandex.Indexer.updateTypeTarget(Indexer.java:1120)
        at org.jboss.jandex.Indexer.updateTypeTargets(Indexer.java:842)
        at org.jboss.jandex.Indexer.index(Indexer.java:1970)
        at io.openliberty.microprofile.openapi20.utils.IndexUtils.indexContainer(IndexUtils.java:110)
        at io.openliberty.microprofile.openapi20.utils.IndexUtils.indexContainer(IndexUtils.java:122)
  ...

This exception should not occur, however this was an issue in jandex which was fixed in version 2.4.1, therefore we fixed this issue by updating jandex to version 2.4.1.

Classes are still indexed by mpOpenAPI when mp.openapi.scan.disable=true

When the config option mp.openapi.scan.disable=true, application classes were still indexed using Jandex even though the result is discarded and isn’t used to generate the OpenAPI document. This was unhelpful since scanning is a relatively slow operation. We expect classes to not be scanned at all. A fix has been implemented so that classes are not scanned at all when scanning is disabled.
Memory Leak with mpJWT

When using JWTs to authenticate into a server, there was a chance a memory leak would occur after running for a long time leading to an OutOfMemory error. A workaround was to disable the authCache by adding the following to the server.xml.
```
<authentication id="Basic" cacheEnabled="false" />
```
In this case, the HashMap in AuthenticationGuard never had entries removed from it because the key used for the put (hashtableAuthData) is different from the key used later to see if it should be removed (authenticationData). This eventually leads to a large HashMap and OOM Error. The change here to fix the issue was to make sure the same key is used in relinquishAccess that was used in requestAccess, which ensures that entries are removed from the HashMap.
New HTTP/2 streams still accepted while server is closing

Due to an oversight in a previous fix, HTTP/2 streams could still be accepted after the server shutdown process begins. This would happen during server shutdown, with a quiesce timeout active, and an HTTP/2 connection actively generating new streams. As long as new streams keep the connection open during the quiesce timeout, the quiesce warning message would be invoked. A similar warning would be logged:
```
CWWKE1106W: 1 shutdown operations did not complete during the quiesce period.
```
During quiesce, connections should begin closing down. In HTTP/1.1 this implies disabling keep-alive. In HTTP/2, sending a GOAWAY once quiesce begins. We have worked on improving the HTTP/2 server shutdown behaviour to fix this issue.
Unresolved gRPC bundles in feature when used alongside servlet-5.0

Previously, the components within the grpc monitor bundles did not properly resolve when running on the Jakarta EE9 servlet-5.0 feature. This bug occurred when gRPC runs alongside the servlet-5.0 feature and some monitoring feature is enabled. For instance, this bug would occur with grpc-1.0 and mpMetrics-4.0. This bug was fixed by updating the range of io.grpc versions for EE9.
JNDI lookup to CORBA URL can hang

A naming lookup that results in the first call to the CORBA COSNaming NameService should cause the service to be activated. However, previously, if two concurrent naming lookups found the service not yet activated, a race condition could have occurred, and one of the calls could have hung. This happened because the activator incorrectly propagates an exception:

org.omg.PortableServer.POAPackage.AdapterAlreadyExists

The NamingServiceAdapterActivator should simply return false to indicate that activation failed. One call should activate the service and use it, and the other call should use the already-activated service. Both calls should succeed. A fix has been implemented to solve this issue.

Get Open Liberty 22.0.0.1 now

Available through Maven, Gradle, Docker, and as a downloadable archive.

MicroProfile 5, MicroProfile Rest Client 3.0 and JPA enhancements in Open Liberty 22.0.0.1-beta

Tue, 30 Nov 2021 00:00:00 +0000

Open Liberty 22.0.0.1-beta offers MicroProfile 5.0, which includes MicroProfile Rest Client 3.0 and aligns with Jakarta EE 9.1. This beta release also introduces the ability to declare "default" JPA persistence properties.

For 22.0.0.1-beta, there is a single beta package for Open Liberty:

All Beta Features: this package contains all Open Liberty beta features and GA features and functions.

This means that you can try out our in-development Open Liberty features by just adding the relevant coordinates to your build tools.

If you give the beta package a try, let us know what you think.

All Beta Features package

The All Beta Features package includes the following beta features and enhancements:

MicroProfile 5.0
MicroProfile Rest Client 3.0
Define JPA persistence properties at server scope

MicroProfile 5.0

MicroProfile 5.0 enables applications to use MicroProfile APIs together with Jakarta EE 9.1. MicroProfile 5.0 does not provide any other functional updates except aligning with Jakarta EE 9.1. MicroProfile 5.0 includes the following features:

Config 3.0
Fault Tolerance 4.0
Rest Client 3.0
Health 4.0
Metrics 4.0
Open Tracing 3.0
Open API 3.0
JWT propagation 2.0.

This beta driver will be used as a compatible implementation for releasing MicroProfile 5.0.

Include the following in the server.xml to enable the MicroProfile 5.0 feature in Open Liberty:

<featureManager>
    <feature>microProfile-5.0</feature>
</featureManager>

Alternatively, you can enable the individual MicroProfile features that you need, for example:

<featureManager>
    <feature>mpOpenTracing-3.0</feature>
</featureManager>

For more information about this update, check out the MicroProfile 5.0 Release on GitHub.

MicroProfile Rest Client 3.0

MicroProfile Rest Client is an API that helps developers to write type-safe interfaces that abstract and invoke remote RESTful services. This is the 3.0 release of MicroProfile Rest Client, and it adds support for Jakarta EE 9.1 technologies. From a developer’s perspective, the only change from the previous release (2.0) is the package space name change of Jakarta packages from javax. to jakarta.. However, another change is that the Open Liberty implementation has changed from Apache CXF to RESTEasy - this change brings with it some behavior and property changes (most of which are already documented as differences between jaxrs-2.1 and restfulWS-3.0).

To use this new feature, you would need to add mpRestClient-3.0 to the featureManager element in the server.xml. The code should be similar to previous versions of MP Rest Client, but the packages should change from javax. to jakarta..

<featureManager>
    <feature>mpRestClient-3.0</feature>
</featureManager>

For more information, check out:

Define JPA persistence properties at server scope

This new JPA enhancement adds the ability to declare "default" JPA persistence properties to all container-managed persistence contexts as a Liberty server.xml configuration.

Previously if a persistence property needed to be set for all persistence.xml configuration files you would manually update all persistence.xml files in all applications. This could end up requiring hundreds of manual updates and/or rebuilding of applications. With this enhancement you can specify persistence properties in the server.xml that will propagate to all container-managed persistence units for applications installed on that server.

To start using the new feature, add the <defaultProperties> configuration element to the <jpa> configuration in your server.xml file. Specify the persistence properties that you want to apply to all container-managed persistence units, as shown in the following examples:

Example 1:

<server>
    <featureManager>
        <feature>persistenceContainer-3.0</feature>
    </featureManager>

    <jpa defaultPersistenceProvider="org.hibernate.jpa.HibernatePersistenceProvider">
        <defaultProperties>
            <property name="javax.persistence.lock.timeout" value="4000"/>
            <property name="hibernate.dialect" value="org.hibernate.dialect.Oracle12cDialect"/>
        </defaultProperties>
    </jpa>
</server>

Example 2:

<server>
    <featureManager>
        <feature>jpa-2.1</feature>
    </featureManager>

    <jpa>
        <defaultProperties>
            <property name="javax.persistence.lock.timeout" value="12345"/>
            <property name="eclipselink.cache.shared.default" value="false"/>
        </defaultProperties>
    </jpa>
</server>

Technical description

These defaultProperties are integration-level persistence properties that are supplied to the specified persistence provider when the PersistenceProvider.createContainerEntityManagerFactory method is called by the JPA Container.

According to the JPA specification (3.4.4.3):

If the same property or hint is specified more than once, the following order of overriding applies, in order of decreasing precedence:
  • argument to method of EntityManager, Query, or TypedQuery interface
  • specification to NamedQuery (annotation or XML)
  • argument to createEntityManagerFactory method
  • specification in persistence.xml

These defaultProperties persistence property values override any properties with the same name that are specified in a persistence.xml file. However, property values specified through PersistenceContext annotation, or the persistence-context-ref deployment descriptor element, or Query Hints property will override these defaultProperties.

Try it now

To try out these features, just update your build tools to pull the Open Liberty All Beta Features package instead of the main release. The beta works with Java SE 17, Java SE 11, or Java SE 8.

If you’re using Maven, here are the coordinates:

<dependency>
  <groupId>io.openliberty.beta</groupId>
  <artifactId>openliberty-runtime</artifactId>
  <version>22.0.0.1-beta</version>
  <type>pom</type>
</dependency>

Or for Gradle:

dependencies {
    libertyRuntime group: 'io.openliberty.beta', name: 'openliberty-runtime', version: '[22.0.0.1-beta,)'
}

Or take a look at our Downloads page.

Jakarta EE 9.1 Beta Features

Are you looking for our regular section regarding Jakarta EE 9.1 Beta feature updates? Well good news, as of 21.0.0.12 the Jakarta EE 9.1 features are now out of beta and fully supported. That means that you can either use them in the official 21.0.0.12 release, or continue to use them in the beta 22.0.0.1-beta package. Just as before, you can enable the individual features you want or you can just add the Jakarta EE 9.1 convenience feature to enable all of the Jakarta EE 9.1 beta features at once:

  <featureManager>
    <feature>jakartaee-9.1</feature>
  </featureManager>

Or you can add the Web Profile convenience feature to enable all of the Jakarta EE 9.1 Web Profile beta features at once:

  <featureManager>
    <feature>webProfile-9.1</feature>
  </featureManager>

Your feedback is welcomed

Let us know what you think on our mailing list. If you hit a problem, post a question on StackOverflow. If you hit a bug, please raise an issue.

Jakarta EE 9.1 support and configurable response headers in Open Liberty 21.0.0.12

Fri, 26 Nov 2021 00:00:00 +0000

Jakarta EE 9.1 support is now available as part of Open Liberty 21.0.0.12, alongside configurable response headers, which offer more granular control over response headers! Several significant bug fixes are also part of this release.

In Open Liberty 21.0.0.12:

Jakarta EE 9.1 support
Configurable Response Headers
Notable bug fixes

Along with the new features and functions added to the runtime, we’ve also made updates to our guides.

Run your apps using 21.0.0.12

If you’re using Maven, here are the coordinates:

<dependency>
    <groupId>io.openliberty</groupId>
    <artifactId>openliberty-runtime</artifactId>
    <version>21.0.0.12</version>
    <type>zip</type>
</dependency>

Or for Gradle:

dependencies {
    libertyRuntime group: 'io.openliberty', name: 'openliberty-runtime', version: '[21.0.0.12,)'
}

Or if you’re using Docker:

FROM open-liberty

Or take a look at our Downloads page.

Jakarta EE 9.1 support

Jakarta EE 9.1 support is now available in Open Liberty!! This support allows you to run Jakarta EE 9.1 applications using Java 8, 11, or 17 with other Open Liberty value-add features that are updated to support Jakarta EE 9.1. Many of you have followed our progress for delivering Jakarta EE 9.1 via our beta releases and corresponding blogs, and we’d like to thank those that provided feedback along the way. If you’re targeting a new application for Jakarta EE 9.1, make sure to use the jakarta namespace. For existing applications that you’d like to move from Java EE (and its javax namespace) to Jakarta EE (and its jakarta namespace) we recommend trying the Eclipse Transformer, an open source project originally developed by members of the Open Liberty team and then contributed to the Eclipse Foundation.

With the RESTful Web Services 3.0 (formerly called JAXRS) support in Open Liberty, there is a significant performance improvement for applications which use the RESTful Web Services function. This performance improvement was achieved by moving our RESTful Web Services implementation from Apache CXF to using RestEasy. With this new version, CDI is enabled by default, and JSON Binding is not enabled by default with the feature being specified in your server.xml.

Any Liberty features with API and/or SPI functions that use Jakarta EE APIs as part of their method signatures have been updated to have their package versions be reset to 10.0 when using those API / SPIs with Jakarta EE 9.1. Any bundles used for user features that depend on those packages will need to change the import package version range when updating the user feature to use Jakarta EE 9.1.

With the introduction of Jakarta EE 9.1, the Jakarta Enterprise Beans 4.0 specification includes a few minor changes over the prior version of the specification, Enterprise JavaBeans (EJB) 3.2, as follows:

Note the new names of the features; all of the same features exist, but the feature name prefix has changed from ejb to enterpriseBeans. For example, enterpriseBeansLite-4.0 is the new version of ejbLite-3.2.
The API package has changed from javax.ejb to jakarta.ejb
The @Schedule annotation is now repeatable
The following API methods have been removed:
- javax.ejb.EJBContext.getCallerIdentity() → use getCallerPrincipal()
- javax.ejb.EJBContext.getEnvironment() → use JNDI lookup in java:comp/env
- javax.ejb.EJBContext.isCallerInRole(java.security.Identity) → use isCallerInRole(String)
- javax.ejb.SessionContext.getMessageContext() (removed with JAX-RPC)

All other capabilities of Enterprise Beans remain the same as the prior specification version (3.2).

Although many of the Jakarta EE 9.1 features have only received a version update, the majority have also had their name changed. The following table lists the features for which both the short name and the version number are changed. To update one of these features for Jakarta EE 9.1, you must change both the feature short name and version number in your server.xml file.

Table 1. Jakarta EE 9.1 feature updates, short name and version
Jakarta EE 9.1 feature name	Java EE/Jakarta EE 8 short name and version	Jakarta EE 9.1 short name and version
Jakarta Enterprise Beans	ejb-3.2	enterpriseBeans-4.0
Jakarta Enterprise Beans Home Interfaces	ejbHome-3.2	enterpriseBeansHome-4.0
Jakarta Enterprise Beans Lite	ejbLite-3.2	enterpriseBeansLite-4.0
Jakarta Enterprise Beans Persistent Timers	ejbPersistentTimer-3.2	enterpriseBeansPersistentTimer-4.0
Jakarta Enterprise Beans Remote	ejbRemote-3.2	enterpriseBeansRemote-4.0
Jakarta Expression Language	el-3.0	expressionLanguage-4.0
Jakarta Authorization	jacc-1.5	appAuthorization-2.0
Jakarta Authentication	jaspic-1.1	appAuthentication-2.0
Jakarta EE Platform	javaee-8.0	jakartaee-9.1
Jakarta EE Application Client	javaeeClient-8.0	jakartaeeClient-9.1
Jakarta Mail	javaMail-1.6	mail-2.0
Jakarta XML Binding	jaxb-2.2	xmlBinding-3.0
Jakarta RESTful Web Services	jaxrs-2.1	restfulWS-3.0
Jakarta RESTful Web Services Client	jaxrsClient-2.1	restfulWSClient-3.0
Jakarta XML Web Services	jaxws-2.2	xmlWS-3.0
Jakarta Connectors	jca-1.7	connectors-2.0
Jakarta Connectors Inbound Security	jcaInboundSecurity-1.0	connectorsInboundSecurity-2.0
Jakarta Messaging	jms-2.0	messaging-3.0
Jakarta Persistence	jpa-2.2	persistence-3.0
Jakarta Persistence Container	jpaContainer-2.2	persistenceContainer-3.0
Jakarta Server Faces	jsf-2.3	faces-3.0
Jakarta Server Faces Container	jsfContainer-2.3	facesContainer-3.0
Jakarta Server Pages	jsp-2.3	pages-3.0
Messaging Server Client	wasJmsClient-2.0	messagingClient-3.0
Messaging Server Security	wasJmsSecurity-1.0	messagingSecurity-3.0
Messaging Server	wasJmsServer-1.0	messagingServer-3.0

For a full overview of what has changed, visit the Jakarta EE 9.1 feature updates page.

To enable the Jakarta EE 9.1 features, add the corresponding feature to your server.xml. You can enable either the individual features you want or you can add the Jakarta EE 9.1 convenience features. For example, to enable all of the Jakarta EE 9.1 features at once add:

<featureManager>
    <feature>jakartaee-9.1</feature>
</featureManager>

Or you can add the Web Profile convenience feature to enable all of the Jakarta EE 9.1 Web Profile features at once:

<featureManager>
    <feature>webProfile-9.1</feature>
</featureManager>

For details regarding the APIs and SPIs, check out the Jakarta EE 9.1 javadoc.

Configurable Response Headers

You can now configure Open Liberty to modify response headers. The available configuration options allow for headers to be appended, for existing headers to be overwritten, for missing headers to be added, and for undesired headers to be removed from all responses being serviced by an HTTP endpoint. This configuration offers more granular control over response headers, which offers a solution to modifying headers without the need to change existing applications, filters, or otherwise.

To use configurable response headers, begin by defining a new element called <headers> in the server.xml. You can configure this for individual HTTP endpoints or for all endpoints at once.

Configuring for individual HTTP endpoints:

<httpEndpoint id="defaultHttpEndpoint"
                  httpPort="9080"
                  httpsPort="9443">

    <headers>
        <add>foo:bar</add>
        <add>foo:bar2</add>
        <set>customHeader:customValue</set>
        <setIfMissing>X-Forwarded-Proto:https</setIfMissing>
        <remove>Via</remove>
    </headers>
</httpEndpoint>

Configuring for all HTTP endpoints:

<httpEndpoint id="defaultHttpEndpoint"
                  httpPort="9080"
                  httpsPort="9443"
                  headersRef="myHeadersID">
</httpEndpoint>

<httpEndpoint id="otherHttpEndpoint"
                  httpPort="9081"
                  httpsPort="9444"
                  headersRef="myHeadersID">
</httpEndpoint>

<headers id="myHeadersID">
    <add>foo:bar</add>
    <add>foo:bar2</add>
    <set>customHeader:customValue</set>
    <setIfMissing>X-Forwarded-Proto:https</setIfMissing>
    <remove>Via</remove>
</headers>

The add attribute allows multiple headers with the same name to be added to a response, similar to the HttpServletResponse’s addHeader API. Similarly, the set attribute is analogous to the setHeader API, which sets a response header to the given name and value. This overwrites existing headers that share the same name. The setIfMissing attribute will only set the configured headers if they are not already present on the response. Lastly, the remove attribute will remove any response headers whose name matches a name defined by the configuration.

Each header entry for the add, set, and setIfMissing attributes can be provided as a stand-alone header name. Optionally, a header value can be added by appending the colon : character after every header name. Note, however, that the remove attribute only expects header names and not a header name:value pair.

As seen in the example above, one way to configure the <headers> element is to declare each individual header within it own add, set, setIfMissing, or remove attribute. In addition to this configuration, headers can be provided as a comma delimited list.

The following server.xml configuration declares individual headers within the desired configuration attributes:

<headers>
    <add>foo:bar</add>
    <add>foo:bar2</add>
    <set>customHeader:customValue</set>
    <setIfMissing>X-Forwarded-Proto:https</setIfMissing>
    <remove>Via</remove>
</headers>

This configuration can also be declared as comma delimited lists, such as:

<headers add="foo:bar, foo:bar2" set="customHeader:customValue" setIfMissing="X-Forwarded-Proto:https" remove="Via"/>

There are three warning messages relating to misconfigurations for this feature. Note that if a configuration value is considered to be misconfigured, it will not be utilized. Furthermore, if the misconfigured value had a non-empty header name, any further configurations with this same name will also be ignored.

The first warning message, CWWKT0042W, will be logged whenever a header name is left empty. While header values are completely optional, the configuration does expect a non-empty header name.

The add configuration allows for multiple headers with the same name to be configured. However, it would be ambiguous to repeat a header name in any other configuration attribute. For instance, consider the set attribute option, which is meant to overwrite an existing header that shared the declared header name. If the set configuration contained two headers with the same name, it would be unclear which of the two values should be chosen. Similarly, if the same header name is present in two or more configurations, the same ambiguity is true. As such, and excluding repetitions in the add configuration, whenever a header name is found to be used more than once, the warning message CWWKT0043W will be logged.

The third warning message, CWWKT0044W, is logged if a header that has already been flagged as a duplicate by the CWWKT0043W warning message, continues to be utilized by further configurations.

Warning Message Descriptions:

CWWKT0042W : An empty header name was found when the 'set` configuration was parsed. This value is ignored.

CWWKT0043W : A duplicate header name was found in the [foo] header using the set configuration. All configurations for the [foo] header are ignored. Any header that is defined by the remove, add, set, or setIfMissing configurations must be unique across all configurations.

CWWKT0044W : The [foo] header, which is marked as a duplicate header name, was found in the set configuration. The [foo] header is ignored. Any header that is defined by the set configuration must contain unique header names.

Summary

Open Liberty now provides a way to control response headers for a given HTTP endpoint. These can be appended, configured to overwrite, to only be added if not already present, or completely removed from all responses. Try it out for yourself!

Notable bugs fixed in this release

We’ve spent some time fixing bugs. The following sections describe just some of the issues resolved in this release. If you’re interested, here’s the full list of bugs fixed in 21.0.0.12.

Throughput performance degradation in eclipselink due to Thread.getStackTrace calls

We discovered an issue where a change to the org.eclipse.persistence.internal.helper.ConcurrencyManager class caused a ~75% throughput performance degradation in eclipselink. This lost throughput was caused by calls to Thread.getStackTrace(). This regression showed up for jpa-2.2 in 21.0.0.8 and persistence-3.0 in 21.0.0.9. This issue has now been fixed by removing the getStackTrace() calls.
MicroProfile OpenAPI 2.0 includes non-public fields in the generated documentation

Previously, when a schema was created for a class which includes a private field, the private field would be listed in the generated OpenAPI document, for example:
```
@Schema
public class Example {
    private String field1;
    public String field2;
}
```
results in
```
  schemas:
    Example:
      type: object
      properties:
        field1:
          type: string
        field2:
          type: string
```
The field field1 should not have appeared in the generated OpenAPI document as it is private. This issue has been fixed by setting the mp.openapi.extensions.smallrye.private-properties.enable property to disable non-public properties by default.

Port bind skipped at server startup

Previously, in an extremely rare scenario, configured ports could silently fail to bind - preventing Liberty from using them. This issue was caused by a subtle race condition in the code responsible for delaying the port bind until the server is ready to handle traffic.

In the failing scenario, the port started message would not be emitted - for example the following message would be missing:

CWWKO0219I: TCP Channel defaultHttpEndpoint has been started and is now listening for requests on host * (IPv4) port 9080.

and the following FFDC will be seen:

Exception = java.lang.RuntimeException
Source = com.ibm.ws.tcpchannel.internal.NBAcceptChannelSelector
probeid = 254
Stack Dump = java.lang.RuntimeException: java.nio.channels.NotYetBoundException
        at com.ibm.ws.tcpchannel.internal.NBAcceptChannelSelector.performRequest(NBAcceptChannelSelector.java:358)
        at com.ibm.ws.tcpchannel.internal.ChannelSelector.run(ChannelSelector.java:257)
        at java.base/java.lang.Thread.run(Thread.java:866)
Caused by: java.nio.channels.NotYetBoundException
        at java.base/sun.nio.ch.ServerSocketChannelImpl.begin(ServerSocketChannelImpl.java:246)
        at java.base/sun.nio.ch.ServerSocketChannelImpl.accept(ServerSocketChannelImpl.java:283)
        at com.ibm.ws.tcpchannel.internal.NBAcceptChannelSelector.performRequest(NBAcceptChannelSelector.java:278)
        ... 2 more

This issue has now been fixed so that all configured ports should start, or if there is a problem some meaningful error message should be logged.

Application fails to restart in server.xml update scenario

We discovered an issue where an application would fail to restart, due to a race condition during server reconfiguration when multiple apps are installed. The problem occurs when one app starts before another app is finished uninstalling. In theory this shouldn’t be a problem - however for this scenario these apps are sharing a VirtualHost configuration object, and in this case one app updates the parent VirtualHost as part of its uninstall process in such a way that the other gets into an invalid state. The server log will show a warning such as CWWKZ0020I: Application <app_name> not updated. This issue was fixed by fixing the race condition that caused the failure.
HTTP upgrade to WebSocket can cause quiesce errors

When a WebSocket connection is started, it starts as an HTTP connection. Previously, If an error occurred during the transition between an HTTP and a WebSocket connection, which was known to be a WebSocket upgrade, the error processing would neglect to decrement a connection counter, which then caused the server to believe there is an open connection during server stop. There were two scenarios where these quiesce errors would occur:
- When a read error occurred during the transition between an HTTP and a WebSocket connection, the error processing neglected to decrement a connection counter, which then causes the server to believe there is an open connection during server stop.
- If a client immediately closed the WebSocket connection after it was opened, the original upgrade request handling may not have had enough time to close properly on the server. Once again, the connection counter failed to decrement leading the server to believe there is an open connection during the server stop.
  
  This issue has been fixed by adding a new flag called decrementNeeded which helps to ensure that the decrement is not neglected.
Ensure ServletRequestListener#requestDestroyed is always called

We discovered a bug where the ServletRequestListener#requestDestroyed call does not occur, if an exception occurs during async servlet while an appSecurity-x.0 is enabled. For this bug to occur, two conditions must be met: the webContainer property deferServletRequestListenerDestroyOnError is true and an appSecurity-x.0 feature is enabled. This issue has now been resolved.

ClassCastException in JSP relating to JDT internal classes

Open Liberty 21.0.0.9 introduced a bug where the following error occurred for certain class lookups in JSP:

Error 500: java.lang.ClassCastException: class org.eclipse.jdt.internal.compiler.lookup.PlainPackageBinding cannot be cast to class org.eclipse.jdt.internal.compiler.lookup.TypeBinding (org.eclipse.jdt.internal.compiler.lookup.PlainPackageBinding and org.eclipse.jdt.internal.compiler.lookup.TypeBinding are in unnamed module of loader org.eclipse.osgi.internal.loader.EquinoxClassLoader @3522bc53)

This issue has now been fixed.

New and updated guides since the previous release

As Open Liberty features and functionality continue to grow, we continue to add new guides to openliberty.io on those topics to make their adoption as easy as possible. Existing guides also receive updates in order to address any reported bugs/issues, keep their content current, and expand what their topic covers.

Creating a multi-module application
- Previously the guide demonstrated how to build an application with multiple modules using Maven and Open Liberty. With this update, it now also introduces how to use the Liberty Maven plug-in to develop a multi-module application in development mode without having to prebuild the JAR and WAR files.

Get Open Liberty 21.0.0.12 now

Available through Maven, Gradle, Docker, and as a downloadable archive.

Meet our open source champions: Andy McCright, Web Services Architect

Mon, 15 Nov 2021 00:00:00 +0000

In this blog series, we’re highlighting some of the amazing individuals who contribute to Open Source software (OSS). We’ll delve into their contributions within OSS, their career journey, how OSS involvement has helped them, and their advice to others for getting involved.

Introduction:

Andy has worked for IBM as an Enterprise Java developer for around 20 years. In that time, he’s worked on various projects, but mostly around WebSphere Liberty Application Server – and currently on Open Liberty. Andy is now a Web Services Architect. He enjoys open source software and contributes to many projects, including Open Liberty, Apache CXF, RESTEasy, Jakarta RESTful Web Services, and MicroProfile ™ (specifically the Rest Client and GraphQL).

Tech introduction:

Jakarta RESTful Web Services, MicroProfile Rest Client and MicroProfile GraphQL are all specification projects. That means that the projects don’t produce anything that is directly usable by an end user, but rather provides APIs for users and rules/guidelines for other projects to implement and provides a compatibility test suite (TCK) for verifying that implementing projects are compatible. These other projects can implement things beyond the specification or simply differentiate themselves by performance or footprint, etc. This allows users to code to the specification APIs, but choose an implementation that best fits their needs.

Jakarta RESTful Web Services (formerly known as JAX-RS) is a specification/API for developing Java RESTful services, primarily using annotations to mark which classes/methods should be invoked when a client makes a specific REST request over HTTP. While it contains some client-side APIs, the MicroProfile Rest Client takes a different and perhaps more user-friendly approach to consuming RESTful services. MicroProfile GraphQL uses a similar annotation approach to JAX-RS, but implements an alternative to the REST architecture that features a query-language allowing clients to specify exactly the data they want to see, saving bandwidth and client-side processing.

Apache CXF and RESTEasy are two different implementations of Jakarta RESTful Web Services and the MicroProfile Rest Client. CXF actually implements many other specifications. Both are modular, so you can choose which pieces of these products you need (i.e. JAX-RS client only vs full JAX-RS server implementation). SmallRye GraphQL is an implementation of the MicroProfile GraphQL specification. It was founded by RedHat and IBM.

All of these technologies are packaged as part of Open Liberty. For developers who want to pick and choose, they can use Liberty’s feature manager to specify only the features they want. This can reduce footprint as well as server startup performance.

What projects have you worked on since joining IBM?
What encouraged you to get started with open source projects? How does working on an open-source community project like this compare to working on a proprietary project?
How has your involvement in open-source projects impacted upon your work or impacted you personally?
How has your role changed since getting involved in open-source? What impact have you been able to have within IBM through your role/involvement?
What is involved in being a web services architect? What are your favourite parts of this role?
How did you get involved in GraphQL? Why did you select this particular API to become involved with within the MicroProfile specification?
As someone who creates many blogs, tutorials, and presentations about these OSS technologies, what motivates or inspires you to create these? What do you gain from these additional advocacy activities?
What inspired/motivated you to co-author your new book, 'Practical Cloud-Native Java Development with MicroProfile'? What does this book offer developers?
What advice would you give to developers that are interested in getting started with an open-source project?
Some Fun Questions…

Q&A:

What projects have you worked on since joining IBM?

Mostly WebSphere Application Server (WAS). I started IBM in 2000 on a specialized systems integration testing team for WAS. Since then, I’ve worked in various different development and support groups, with a brief stint in WebSphere eXtreme Scale. After WXS, I moved back to the WAS org, but mainly focused on WebSphere Liberty and a lesser-known (and now extinct) project called WAS Community Edition (based on Apache Geronimo). Now I primarily work on Open Liberty.

What encouraged you to get started with open source projects? How does working on an open-source community project like this compare to working on a proprietary project?

To be honest, open source software was a little frightening for me at first. It’s one thing to write code that only a few of your peers can see. It’s another thing to write code that the whole world can see (and critique!). What helped me to get started was an experienced mentor who would pre-review my changes before I submitted them to the community. This helped to build my confidence - similar to training wheels when learning to ride a bike. Eventually, the training wheels came off and I was part of the community.

I think open source and proprietary projects really aren’t that different anymore. Even proprietary projects use a lot of open source paradigms - like reporting issues in trackers like JIRA, and document their projects using wikis, and track source code changes using Git, etc. Probably the biggest difference between open source projects and proprietary projects is the culture. In proprietary projects like WAS or WXS, there was a single culture, set of tools, etc. But when you work with different open source projects, you may end up using different tools - one project might want to communicate over email lists while another may prefer Slack or Gitter. You end up working with people from different companies in different countries and timezones.

How has your involvement in open-source projects impacted upon your work or impacted you personally?

In a way, I think it has made me more worldly. I’ve built professional (and in some cases personal) relationships with people from multiple continents. I’ve learned a lot, like how to use new coding practices, improved tooling, and working with different personalities. I’ve also enjoyed the direct interaction with users.

How has your role changed since getting involved in open-source? What impact have you been able to have within IBM through your role/involvement?

Early in my career, I got some great advice (if a little buzzwordy…): build your brand; "be the guy". A few years ago, my management team asked me to lead the JAX-RS team for IBM. I had to learn a lot about REST and how we implemented it in a short time. This got me involved in the Apache CXF project, where I’ve carved a small niche - mostly JAX-RS and later MicroProfile Rest Client. I’m starting to create a similar niche with RESTEasy. I’ve also become IBM’s representative to the open source specification projects for Jakarta RESTful Web Services (the new name for JAX-RS) and MicroProfile Rest Client. In effect, I’ve become the "REST guy".

My role has definitely changed from one that primarily fixed bugs to one that creates new features. My role has also added new facets, like advocacy. I’ve been doing a lot more work-related social media (Twitter, LinkedIn, blogging) in concert with open source development. I’ve really enjoyed that aspect of my job. It’s also now super-easy to create a new feature and then demo it on GitHub and blog about it with links to the source code. I think that really helps our users out - they know what our products can do and can see it working - and if they run into problems, they can talk directly with us over GH issues or StackOverflow, etc.

What is involved in being a web services architect? What are your favorite parts of this role?

More meetings… :-) Aside from the meetings, there is a lot of flexibility in my role. Some days, I’ll work on product defects, while others I might help write documentation, and still others I might try to hype some new feature that our team recently delivered. It definitely involves working with a lot of people . For a generally introverted person like me, it’s strange, but I kinda like that. There’s a lot to like about my role. I like writing blog posts - more the how-to stuff than the marketing stuff, but I like both. I also like the feeling of accomplishment when completing a new feature, particularly when it is one that solves a real user problem.

How did you get involved in GraphQL? Why did you select this particular API to become involved with within the MicroProfile specification?

Our chief architect went to a conference where an attendee asked about GraphQL. He said, "we’re planning to work on that". When it was almost time for the same conference the next year, he pulled me aside and said, "can you work on this so that when I see this user again, I won’t be a liar?" I did a little research into GraphQL and found it to be a very interesting technology. It seemed to have a large following in languages like JavaScript, but not so much in Java. I considered just adding a GraphQL implementation directly in Open Liberty, but I figured that it would be better to get more buy-in from others in the industry, and I found a few folks who were interested in GraphQL who had already posted on the MicroProfile mail list. We got together and built a sandbox implementation of GraphQL, and eventually built a fully supported release. Now users can develop GraphQL applications in Java and run them in Liberty, Wildfly, Quarkus and Helidon.

In fact, if you’d like to learn more about MicroProfile GraphQL, then check out my IBM ExpertTV Episode.

As someone who creates many blogs, tutorials, and presentations about these OSS technologies, what motivates or inspires you to create these? What do you gain from these additional advocacy activities?

I enjoy writing. I’m sure that in some alternate universe, I ended up as a bestselling novelist instead of a software engineer. But aside from the sheer enjoyment of writing, I like to blog or write tutorials to share my knowledge and help people. I suppose it’s a bit like giving back. I also like to blog as it helps with my brand, as I mentioned earlier. That certainly helps my career. While I’m not really looking for a new job at the moment, if things changed, it should certainly help my prospects if a potential employer can google my name and find a bunch of blog posts and links to projects I’ve worked on, etc.

I get less enjoyment from presentations - and quite honestly, that’s a stretch for me as I have a bit of stage-fright. But I do that for a few different reasons. (1) I think it is an expected part of my job. (2) It certainly helps with my personal brand, and (3) I also enjoy traveling - so this provides a great way to visit some amazing locations. On that point, I’ve been extremely fortunate at IBM to have been able to travel to conferences or user groups in Vienna, Paris/Toulouse, Beijing, Johannesburg, New York, Las Vegas, San Jose, and Minneapolis.

What inspired/motivated you to co-author your new book, Practical Cloud-Native Java Development with MicroProfile? What does this book offer developers?

I hope I’m not sounding like a broken record by this point, but I really like to write! :-) Emily Jiang had been in communication with Packt Publishing and had worked out a rough plan for a book on MicroProfile development. This is one example where "personal brand" pays off, as Emily recognized me as "the REST guy" and asked me to help with some of the chapters related to JAX-RS, MicroProfile Rest Client, GraphQL, etc. I was thrilled to accept! The book offers deep advice for developing with the MicroProfile APIs and technologies, but also the best practices for building, deploying, monitoring and maintaining applications in the cloud. My co-authors bring a lot of depth in their subject areas, and we use a real-world application to demonstrate MicroProfile.

If you’re interested in reading this book, then head over to Packt’s website.

What advice would you give to developers that are interested in getting started with an open-source project?

(1) Be patient. It will take a while - and usually a lot of contributions over an extended time before a project will make you a committer. (2) Set realistic goals and expectations. If your goal is to suggest improvements for a product that you use (but not actually implement the improvement yourself), you might need to adjust expectations for when that new feature might be implemented. (3) Be willing to do jobs nobody else wants to do. For many open source projects, that will probably be documentation or testing. Most people want to write the code, and that’s great, but for an open source project to succeed, it will need some quality assurance, documentation, and people answering user questions in the mail lists, forums, etc.

Some Fun Questions…

Favorite food?

Pizza - yep, I’m in my early 40s but I still eat like a college freshman… :)

Music you’re listening to?

Right now, I’m pretty hooked on a band called Remedy Drive - they’ve got an Imagine Dragons vibe.

What do you do when you’re not coding/blogging/etc.?

My wife and three kids keep me pretty busy. I’m also pretty active in my church. I play electric bass on the praise team and try to manage the scheduling - ironically, I do a bit of RESTful programming to interact with the church’s scheduling software! I also play recreational volleyball.

Where do you blog?

My personal blog site is https://andymc12.net/, but I also have blog posts on the Open Liberty blog, DZone, and DEV.

Favorite tools?

I code in VS Code (favorite) and Eclipse. I like Git and GitHub. For diagnosing problems with REST and GraphQL, I really like tcptunnel. It’s a simple proxy-like tool that will display the HTTP data sent over the wire, but less invasive than things like WireShark. I’m a big fan of Slack - it’s basically replaced email for me.

Mac, Windows or Linux?

Mac. I used Linux before that - it’s more customizable and more hard-core nerdish, but I think Mac is a little more polished - and fewer kernel rebuilds. :-)

Getting started with open source

If this article has helped inspire you to get started contributing to open source, why not consider contributing to Open Liberty? It’s easy to get started: https://openliberty.io/contribute/.

MicroProfile 5.0 aligns with Jakarta EE 9.1 and MicroProfile OpenAPI support for multi-module applications in 21.0.0.12-beta

Tue, 02 Nov 2021 00:00:00 +0000

Open Liberty 21.0.0.12-beta supports some of MicroProfile 5.0 features to align with the Jakarta EE 9.1, allowing you to use MicroProfile together with Jakarta EE 9.1 applications. This release also features updates to MicroProfile OpenAPI, as it provides support for multiple applications.

We have two beta packages for Open Liberty:

All Beta Features: a larger package that contains all Open Liberty beta features (including Jakarta EE 9 beta features) and GA features and functions.
Jakarta EE 9 Beta Features: a lightweight package that contains only the Jakarta EE 9 features.

This means that you can now try out our in-development Open Liberty features by just adding the relevant coordinates to your build tools.

If you try either package, let us know what you think.

All Beta Features package

The All Beta Features package includes the following beta features:

MicroProfile JWT 2.0
MicroProfile Health 4.0
MicroProfile Metrics 4.0
MicroProfile Open API 3.0
MicroProfile Fault Tolerance 4.0
MicroProfile Config 3.0
Support multiple applications in mpOpenApi-2.0

MicroProfile JWT 2.0

With this beta, the MicroProfile JSON Web Token 2.0 feature replaces javax with jakarta in Jakarta package names allowing it to be used for Jakarta EE 9.1 applications. The old MicroProfile JSON Web Token 1.2 feature does not provide support for Jakarta EE 9.1 applications. Enabling mpJwt-2.0 instead of mpJwt-1.2 will allow those applications to use the MicroProfile JSON Web Token 2.0 feature.

You can enable the MicroProfile JSON Web Token 2.0 feature by using the mpJwt-2.0 feature in the server.xml file:

<featureManager>
  <feature>mpJwt-2.0</feature>
</featureManager>

All the attributes of the mpJwt element and all the current MP Config properties from the MP JWT 1.2 specification remain the same.

To find out more visit:

MicroProfile Health 4.0

This feature mpHealth-4.0 is the implementation of the Eclipse MicroProfile Health 4.0 release, which aligns with Jakarta EE 9.1. This feature replaces javax with jakarta in Jakarta package names allowing it to be used for Jakarta EE 9.1 applications. There is no other functional changes introduced in this feature. With this feature, you can use MicroProfile together with Jakarta EE 9.1, whereas in prior releases and versions of MicroProfile Health were for the Java EE platform and did not provide support for Jakarta EE 9.1 applications.

You can enable the MicroProfile Health 4.0 feature by using the mpHealth-4.0 feature in the server.xml file:

<featureManager>
  <feature>mpHealth-4.0</feature>
</featureManager>

To find out more visit:

MicroProfile Metrics 4.0

The MicroProfile Metrics 4.0 feature is the implementation of the Eclipse MicroProfile Metrics 4.0 release. This release (and feature) replaces javax with jakarta in Jakarta package names allowing it to be used for Jakarta EE 9.1 applications. Prior releases and versions of MicroProfile metrics were for the Java EE or Jakata EE 8 platform releases. This latest v4.0 release aligns with the Jakarta EE 9.1 platform release.

You can enable the MicroProfile Metrics 4.0 feature by using the mpMetrics-4.0 feature in the server.xml file:

<featureManager>
  <feature>mpMetrics-4.0</feature>
</featureManager>

To find out more visit: * MicroProfile Metrics 4.0 Specification * MicroProfile Metrics 4.0 Release Page * Release Notes

MicroProfile Open API 3.0

This feature mpOpenAPI-3.0 is the implementation of MicroProfile OpenAPI 3.0, which aligns with Jakarta EE 9.1. There is no other functional changes introduced in this feature. With this feature, you can use MicroProfile Open API together with Jakarta EE 9.1.

You can enable the MicroProfile Open API 3.0 feature by using the mpOpenAPI-3.0 feature in the server.xml file:

<featureManager>
  <feature>mpOpenAPI-3.0</feature>
</featureManager>

To find out more visit: * MicroProfile OpenAPI 3.0 Specification * MicroProfile OpenAPI 3.0 Release Page * Release Notes

MicroProfile Fault Tolerance 4.0

This feature mpFaultTolerance-4.0 is the implementation of MicroProfile Fault Tolerance 4.0, which aligns with Jakarta EE 9.1. There is no other functional changes introduced in this feature. With this feature, you can use MicroProfile together with Jakarta EE 9.1.

You can enable the MicroProfile Fault Tolerance 4.0 feature by using the mpFaultTolerance-4.0 feature in the server.xml file:

<featureManager>
  <feature>mpFaultTolerance-4.0</feature>
</featureManager>

To find out more visit: * MicroProfile Fault Tolerance 4.0 Specification * MicroProfile Fault Tolerance 4.0 Release Page * Release Notes

MicroProfile Config 3.0

This feature mpConfig-3.0 is the implementation of MicroProfile Config 3.0, which aligns with Jakarta EE 9.1. There is no other functional changes introduced in this feature. With this feature, you can use MicroProfile together with Jakarta EE 9.1.

You can enable the MicroProfile Config 3.0 feature by using the mpConfig-3.0 feature in the server.xml file:

<featureManager>
  <feature>mpConfig-3.0</feature>
</featureManager>

To find out more visit: * MicroProfile Config 3.0 Specification * MicroProfile Config 3.0 Release Page * Release Notes

Support multiple applications in mpOpenApi-2.0

MicroProfile OpenAPI helps you document the REST endpoints of your application by creating and serving documentation in the OpenAPI format.

To enable this functionality, you must set the MicroProfile Config property mp.openapi.extensions.liberty.merged.include=all, e.g. by adding this to your server.xml:

<variable name="mp.openapi.extensions.liberty.merged.include" value="all"/>

With this property set, deploy several JAX-RS applications and visit /openapi/ui on your Open Liberty server where you should see documentation for all the applications.

The following MP Config properties can be used to configure this feature:

Name Description Default Values

Name	Description	Default	Values
`mp.openapi.extensions.liberty.merged.include`	List of modules which should be included in the merged OpenAPI documentation	`first`	`all` (to include all applications) `first` (to include only the first web module deployed, matching the previous behavior) comma-separated list of `<appname>` (to include individual applications) and `<appname>/<modulename>` (to include individual modules within an EAR)
`mp.openapi.extensions.liberty.merged.exclude`	List of modules which should be excluded from the merged OpenAPI documentation Takes priority over the list of included modules	`none`	`none` (to exclude nothing) comma-separated list of <appname> (to exclude individual applications) and <appname>/<modulename> (to exclude individual modules within an EAR)
`mp.openapi.extensions.liberty.merged.info`	This property sets the info section of the final Open API document	N/A	The value must be a valid OpenAPI info section in JSON format. If this property is set, the info section in the final OpenAPI document is replaced with the value of the property. This replacement is made after any merging is completed.

mp.openapi.extensions.liberty.merged.include

List of modules which should be included in the merged OpenAPI documentation

first

all (to include all applications)
first (to include only the first web module deployed, matching the previous behavior)
comma-separated list of <appname> (to include individual applications) and <appname>/<modulename> (to include individual modules within an EAR)

mp.openapi.extensions.liberty.merged.exclude

List of modules which should be excluded from the merged OpenAPI documentation
Takes priority over the list of included modules

none

none (to exclude nothing)
comma-separated list of <appname> (to exclude individual applications) and <appname>/<modulename> (to exclude individual modules within an EAR)

mp.openapi.extensions.liberty.merged.info

This property sets the info section of the final Open API document

N/A

The value must be a valid OpenAPI info section in JSON format. If this property is set, the info section in the final OpenAPI document is replaced with the value of the property. This replacement is made after any merging is completed.

Try it now

To try out these features, just update your build tools to pull the Open Liberty All Beta Features package instead of the main release. The beta works with Java SE 17, Java SE 11, or Java SE 8.

If you’re using Maven, here are the coordinates:

<dependency>
  <groupId>io.openliberty.beta</groupId>
  <artifactId>openliberty-runtime</artifactId>
  <version>21.0.0.12-beta</version>
  <type>pom</type>
</dependency>

Or for Gradle:

dependencies {
    libertyRuntime group: 'io.openliberty.beta', name: 'openliberty-runtime', version: '[21.0.0.12-beta,)'
}

Or take a look at our Downloads page.

Jakarta EE 9 Beta Features package

Open Liberty is the first vendor product to be Jakarta EE Web Profile 9.0 compatible since the 21.0.0.2-beta release. Open Liberty is also the first vendor product to be added to the Jakarta EE Platform 9.0 compatibility list, with the release of 21.0.0.3-beta. That same beta release was then also used to add Open Liberty to the Jakarta EE Platform 9.1 compatibility list. Open Liberty 21.0.0.6-beta further expanded on this compatability by including new Jakarta EE9 supporting features, and 21.0.0.12-beta offers the same compatability with Jakarta EE9 with performance enhancements.

Enable the Jakarta EE 9 beta features in your app’s server.xml. You can enable the individual features you want or you can just add the Jakarta EE 9 convenience feature to enable all of the Jakarta EE 9 beta features at once:

  <featureManager>
    <feature>jakartaee-9.0</feature>
  </featureManager>

Or you can add the Web Profile convenience feature to enable all of the Jakarta EE 9 Web Profile beta features at once:

  <featureManager>
    <feature>webProfile-9.0</feature>
  </featureManager>

Try it now

To try out these Jakarta EE 9 features on Open Liberty in a lightweight package, just update your build tools to pull the Open Liberty Jakarta EE 9 Beta Features package instead of the main release. The beta works with Java SE 17, Java SE 11, or Java SE 8.

If you’re using Maven, here are the coordinates:

<dependency>
    <groupId>io.openliberty.beta</groupId>
    <artifactId>openliberty-jakartaee9</artifactId>
    <version>21.0.0.12-beta</version>
    <type>zip</type>
</dependency>

Or for Gradle:

dependencies {
    libertyRuntime group: 'io.openliberty.beta', name: 'openliberty-jakartaee9', version: '[21.0.0.12-beta,)'
}

Or take a look at our Downloads page.

Your feedback is welcomed

Let us know what you think on our mailing list. If you hit a problem, post a question on StackOverflow. If you hit a bug, please raise an issue.

A Fun Cup of Joe - Find Out Why Open Liberty is Your Next Cloud Native Java Runtime

Tue, 26 Oct 2021 00:00:00 +0000

Why Open Liberty?

I recently had the opportunity to lead a discussion at a meeting of the Philadelphia Java User Group (JUG) meetup where I highlighted the latest features and design ideas contained within Open Liberty. As part of that discussion I ran two demos where I created and interacted with an Open Liberty-hosted RESTful web service as an application developer - both in a local developer environment and live in a remote Kubernetes cluster environment. As the popularity of a microservice architecture and cloud-native application development experience grows, it is an exciting time to talk about the Open Liberty framework’s support of those models.

The presentation focused on how Open Liberty highly optimizes the development of microservices by using Eclipse MicroProfile and Jakarta EE APIs. To highlight Open Liberty as a flexible, fast, and lightweight Java runtime, the discussion touched on important Open Liberty framework design attributes such as:

Simple configuration enabling "Just Enough Runtime" which allows for the configuration of only the subset of features an application needs at runtime
Low operating cost due to a reduced memory footprint based on that minimal configuration
Zero migration
Kubernetes optimizations
An efficient rapid developer experience

Additionally, the fact that Open Liberty supports the deployment of Spring Boot applications generated an enthusiastic question from a member of the audience interested in understanding how Open Liberty could help a shop with hundreds of Spring Boot applications become more efficient.

Open Liberty in Action

The second half of the Open Liberty overview detailed its rich developer experience through Open Liberty’s support of rapid development using a tight inner-loop experience that’s provided by the Liberty Maven Plugin. In the first demo, code and configuration updates were shown to take place immediately in a local running Open Liberty runtime instance that was managed by the Liberty Maven Plugin on behalf of the developer, with test cases running to automatically provide immediate developer feedback. In the second demo, Open Liberty’s Kubernetes integration points were demonstrated, showing that same developer inner-loop experience occurring in a remote development cluster hosted in a Red Hat OpenShift environment.

Feel free to check out video segments of the discussion at the following links:

Open Liberty Overview
Demo 1 - Developing locally with Open Liberty’s dev mode

By demonstrating a Java RESTful application being enhanced locally in an IDE, the participants were able to see the quick turnaround time developers can achieve using the dev mode feature of the Liberty Maven Plugin.
Open Liberty and Kubernetes Optimizations
Demo 2 - Developing live in a Kubernetes environment with Open Liberty

Participants were able to observe in real-time the effect of an application code update being reflected automatically in a remote Kubernetes cluster by using the OpenShift Do (odo) tool and the java-openliberty development stack, in conjunction with the same Liberty Maven Plugin to manage the OpenShift interactions on the developer’s part.
Open Liberty Summary

The Philadelphia JUG meetup presentation was well attended with 35+ attendees joining via the meetup’s web conferencing tool. The host of the meetup was excited for the group to hear about the strengths of Open Liberty and its developer experience, and I was happy for the opportunity to speak with them. If your group is interested in hearing more, please feel free to reach out to YK and team to schedule a similar discussion at any time.

Meet our open-source champions: Kathryn Kodama, Developer Experience Champion

Tue, 19 Oct 2021 00:00:00 +0000

Introduction:

Kathryn is a software developer on the Open Liberty Developer Experience team at IBM Canada. She has contributed to a number of open-source projects within the MicroProfile ™ and Jakarta EE ™ community, such as the Language Server for MicroProfile (Eclipse LSP4MP), the Language Server for Jakarta EE (Eclipse LSP4Jakarta), and the MicroProfile Starter for Visual Studio Code (VS Code). Kathryn has also contributed to the development of dev mode for OpenLiberty, and corresponding editor plugins.

Tech introduction:

Recently, Kathryn has been working on and contributing to the following projects:

Open Liberty Dev Mode is a hot deployment tool that is made available as a goal of the Liberty Maven plug-in or as a task of the Liberty Gradle plug-in. This enables developers to iterate quickly when developing their cloud-native Java applications with Open Liberty.

The Language Server for MicroProfile (Eclipse LSP4MP) and Language Server for Jakarta EE (Eclipse LSP4Jakarta) both offer language specific support in an IDE or editor for their respective technologies. They help to deliver language support capabilities, such as diagnostics, code completes, hover for more information, directly within the developer’s IDE of choice.

The MicroProfile Starter for VS Code which makes use of the MicroProfile Starter, the VS Code Extension Pack for MicroProfile, and the Open Liberty Tools for VS Code and IntelliJ projects are all IDE specific plugins that users can download from the VS Code or IntelliJ marketplace.

The Open Liberty Tools extensions for VS Code and IntelliJ are currently available as tech previews and offer additional in-editor support for your Open Liberty projects. Both extensions contribute commands to easily start and stop Open Liberty dev mode, as well as run tests and view test reports.

Why is developer experience important? What is involved in this role? Give a brief description of the day-to-day activities you do in this role.
What benefits do the plugins you mentioned offer?
How can open-source projects create better developer experiences? Could you give an example?
In addition to contributing to code within these open source projects, what other contributions have you made? (i.e. documentation, tutorials, blogs, etc)
What impact have open-source projects had on your work or on you personally?
How did your internship help you to transition to a full-time role?
As someone who is regularly involved with local universities, how do you see open-source projects viewed by students?
What advice would you give to developers that are interested in getting started with an open-source project?
Outside of work, what do you like getting up to?

Q&A:

Why is developer experience important? What is involved in this role? Give a brief description of the day-to-day activities you do in this role

Developer experience is important because creating a positive experience for developers will enable them to be more productive and create quality software. A better experience for developers means that more developers will be inclined to continue using our products.

On the Liberty Developer Experience team, there are a number of projects we regularly contribute to. My day-to-day involves adding enhancements to dev mode (recently adding multi-module support for Maven projects), or any of the IDE extensions we support, such as the MicroProfile Starter for VS Code, or Open Liberty Tools for IntelliJ tech preview. Part of this role also involves talking about our tools at conferences and keeping up with the open-source MicroProfile and Jakarta EE community.

What benefits do the plugins you mentioned offer?

IDE plugins, specifically the ones our team works on for MicroProfile and Open Liberty, offer our users an improved experience within their editors. From within their IDE, they are able to use tools like the MicroProfile Starter or Open Liberty dev mode, without having to reference external documentation or visit an external site. This enables developers to focus on the actual code of their application, as opposed to some of the details around initially creating a project, configuring Open Liberty, and deploying to a server. The Liberty developer experience team supports a number of editor plugins, such as the MicroProfile Starter for VS Code, the Generator for MicroProfile REST Client in VS Code, and Open Liberty Tools for VS Code and IntelliJ.

How can open-source projects create better developer experiences? Could you give an example?

By developing our projects in the open-source, we can receive direct feedback from our users through avenues like GitHub issues. Open-source projects also allow us to collaborate with other interested parties in order to build better tools for developers. For example, both our team and developers at Red Hat are actively contributing to Eclipse LSP4MP, the Language Server for MicroProfile. When there is a technology like MicroProfile that is widely used by many developers, it is helpful to be able to leverage the community to build these tools, as they are also the ones that will benefit from using them.

In addition to contributing to code within these open source projects, what other contributions have you made? (i.e. documentation, tutorials, blogs, etc)

I have contributed to the documentation on our IDE extensions; Open Liberty Tools for IntelliJ and VS Code, MicroProfile Starter for VS Code, the VS Code Extension Pack for MicroProfile (Tools for MicroProfile), etc. I have also created blog posts about our Open Liberty Tools for IntelliJ initial tech preview release, and the Language Server for MicroProfile (Eclipse LSP4MP). Beyond these forms of communication, I have spoken at a number of presentations and conferences with the team.

What impact have open-source projects had on your work or on you personally?

Being involved in open-source projects has greatly improved my technical skills and introduced me to a whole new community of developers. I have really enjoyed having the opportunity to network and meet many new people in the community, whether through conferences or directly in pull request comments. I have also gained a deeper understanding of technologies like MicroProfile and Jakarta EE which has made me a stronger Java developer.

How did your internship help you to transition to a full-time role?

My internship gave me the opportunity to ensure that this is the right role for me as I start my career. As an intern I was given ample opportunity to experience the different aspects of my current role, from development to testing, presenting at conferences, meeting my team, and getting involved in volunteer opportunities like STEM for Girls.

Given my positive internship, I was able to confidently transition into my full-time role as I knew the technologies, the kind of work I would be doing, the team, and that IBM was the best company for me as I knew I had support to pick up new projects, learn new technologies, and pursue volunteer opportunities.

As someone who is regularly involved with local universities, how do you see open-source projects viewed by students?

From my perspective, now more than ever students are looking to contribute to open-source projects in order to build their technical skills, portfolios and their networks. The challenge comes in helping students find an open-source project they are interested in and getting over the hurdle of a first commit or pull request. We can help by raising awareness for our projects, through blog posts, youtube videos, etc. and participating in programs that help introduce students to open-source software development.

Our team has been collaborating with a the Canada Open Source Projects (CANOSP) academic program throughout the past year. This program connects students with open-source projects and mentors in exchange for course credit. With this program we have seen a lot of interest from students when contributing to open-source projects. Open-source software clubs are also becoming more prevalent on university campuses. These are clubs where students get together and find open-source projects to contribute to as a group.

What advice would you give to developers that are interested in getting started with an open-source project?

Seek out programs or clubs that help beginners get started contributing to open-source software, whether that is an academic program like the Canadian Open Source Projects (CANOSP) academic program or an event like Hacktoberfest. Seek out projects that you interest you or perhaps you have used in some of your other work. You can also filter by the "good first issue" tag on GitHub to find issues that need to be picked up that have been specifically tagged as good introductory issues on open-source projects. Do not be afraid to open your first PR, maintainers of these projects will be happy to see others contributing them and helpful in the comments!

Outside of work, what do you like getting up to?

Lately I have been camping and hiking a lot as that is one of the safer activities to do throughout the pandemic. I have really enjoyed spending more time outside and getting to visit many of the beautiful provincial parks here in Ontario!

Getting started with Open Source

If this article has helped inspire you to get started contributing to open source, why not consider contributing to Open Liberty. It’s easy to get started: https://openliberty.io/contribute/

MicroProfile, Jakarta EE, Open Liberty, and Java at EclipseCon 2021

Mon, 11 Oct 2021 00:00:00 +0000

EclipseCon is back again as a free, virtual event! EclipseCon (25th-28th October) is a leading conference for developers, architects, and open source business leaders to learn about Eclipse technologies, share best practices, and more. It connects the Eclipse ecosystem and the industry’s leading minds to explore common challenges and innovate together around:

open source runtimes, tools, and frameworks for cloud and edge applications
IoT
artificial intelligence
connected vehicles and transportation
digital ledger technologies
and much more!

If you’re also going to be there, deciding which of the great talks to see at EclipseCon could prove to be challenging with so many fantastic sessions on offer. So we’ve put together a helpful summary of the sessions on MicroProfile, Jakarta EE, Open Liberty and OpenJ9.

Community Day at EclipseCon 2021

EclipseCon Community Day is on Monday, October 25 13:00 - 17:45 CET (the day before the start of the main EclipseCon conference). Community Day is focused on and around working groups and Eclipse projects. The content is organized by the community groups themselves, with logistical support provided by the conference team. Anyone who is registered for EclipseCon 2021 may participate in Community Day; no extra signup is required.

Here are two of the fantastic sessions being run by members of the Open Liberty team:

MicroProfile Current and Future

In this session, MicroProfile lead Emily Jiang is going to bring you up to date with the latest MicroProfile news and then briefly discuss the future roadmap for MicroProfile. Come along to this session to listen, ask questions and find out more about MicroProfile’s contunued innovation and transformation.
Jakarta REST - Looking Ahead

In this session, Jakarta REST lead Andrew McCright will intorduce Jakarta RESTful Web Services (a.k.a. JAX-RS) - one of the more active and popular APIs in the Jakarta EE family. He’ll also explore the future of this Jakarta EE component to see how these APIs will evolve and how you can contribute. This session will also leave time for interactive Q&A, so bring questions, ideas, complaints, and other feedback with you.

Talks at EclipseCon 2021

A selection of MicroProfile, Jakarta EE, Open Liberty, and OpenJ9 sessions:

Tuesday 26th

Optimizing Java Workloads for Containers and Hybrid Cloud Deployments

Open J9’s Vijay Sundaresan and Mark Stoodley will review these latest innovation available to Java users, including Virtual Machine technologies (e.g., in Eclipse OpenJ9) to optimize Java workloads for containers and cloud. They’ll delve into how these innovations benefit cloud-native runtimes (e.g., Open Liberty), and discuss how you can adopt them to optimize your cloud-native Java application and microservice deployments for performance (e.g., fast startup and throughput), efficiency (e.g., memory footprint and consumption) and hence, cost savings.
Powering Java on Azure with Open Liberty and OpenShift

Graham Charters will team up with Microsoft’s Principal Architect Edward Burns to lead this fast-paced hands-on workshop, where you’ll see first-hand how to run Java EE, Jakarta EE, and MicroProfile applications on Open Liberty on Azure Red Hat OpenShift (ARO). The combination of ARO with Open Liberty offers a powerful and flexible platform for your enterprise Java applications.
Equipping the Next Generation of Open-Source Developers

Open Source has become the de facto way to build software. So, how and what are we doing in enabling the next-generation of up-and-coming developers to participate in open-source software development? Join Open Liberty’s YK Chang and Kathryn Kodama, with Karim Ali and Jeff Cho, as they take a look at the Canada Open-Source Projects (CANOSP) program. They will explore the program’s experience and successes, and what they have learned from advocating for open source and equipping university and college students to participate in open-source software development

Wednesday 27th

Instant On Java Cloud Applications with Checkpoint and Restore

Thomas Watson will discuss a different approach to achieve "Instant On" for Java applications using Checkpoint/Restore in Userspace (CRIU). CRIU is a Linux feature that takes a snapshot of a running application. This snapshot can then be restored very quickly from the point the snapshot was taken and resume serving the application users. This session will alo include a demo of using this approach with OpenJ9 and Open Liberty in a (Docker) container image.

Thursday 28th

MicroProfile 4.0 and beyond

Java Champion Emily Jiang will discuss how MicroProfile has evolved to become a standard body for developing cloud-native APIs. She’ll bring you up to date with the new features in MicroProfile 4.0 with a live demo and briefly discuss what is next for this open source project. Come to this session to get yourself updated with the latest news on MicroProfile.
Replicating production on your laptop using the magic of containers

Grace Jansen introduces the concept of test containers within this session and delves into why utilising containers to test our cloud-native applications can enable us to ensure our tests are replicating our production environment as closely as possible. She’ll demo live how Testcontainers can help you run and test with true-to-production environments in development with minimal re-writing of your test code.
MicroProfile GraphQL and JPA: Meant for each other

In this session, Open Liberty’s Andrew McCright and Adam Anderson will discuss and demo how you can rapidly build data-driven microservices using MicroProfile GraphQL - a tool that makes it simple to create Java-based GraphQL services with a few annotations. This session will demonstrate the power and simplicity of making a relational database accessible as a service or cloud-native environment.

Here’s a couple of talks about broader Java topics that may also be of interest:

What’s New in Java? by Manoj Palat (Eclipse Project Lead for Java Development Tools - Java Compiler and friends, IBM)
Dealing with Verification Data Overload by Shelley Lambert, Lan Xia and Renfei Wang (Eclipse AQAvit Committers, RedHat and IBM).
How to analyze Java performance problems in Eclipse using a profiler? by Vikas Chandra (Eclipse Plugin Development Environment Project Lead, IBM)
Structured Concurrency with Project Loom by Sarika Sinha (Eclipse Platform and JDT Project Lead, IBM)

You can find the full schedule on the conference website. See you then!

Configurable Response Headers and more exciting new features in Open Liberty 21.0.0.11-beta

Tue, 05 Oct 2021 00:00:00 +0000

Open Liberty 21.0.0.11-beta provides new configurable response headers, which offer more granular control over response headers. This beta release also introduces important changes to the Jakarta EE convenience features, with the removal of Jakarta EE 9.0 features in the transition to Jakarta EE 9.1.

We have two beta packages for Open Liberty:

All Beta Features: a larger package that contains all Open Liberty beta features (including Jakarta EE 9.1 beta features) and GA features and functions.
Jakarta EE 9.1 Beta Features: a lightweight package that contains only the Jakarta EE 9.1 features.

This means that you can now try out our in-development Open Liberty features by just adding the relevant coordinates to your build tools.

If you try either package, let us know what you think.

All Beta Features package

The All Beta Features package includes the following beta features:

Configurable Response Headers

Configurable Response Headers

You can now configure Open Liberty (21.0.0.11-beta) to modify response headers. The configuration options enable you to:

append headers;
overwrite existing headers;
add missing headers; and
remove undesired headers from all responses that are serviced by an HTTP endpoint.

This granular control over response headers means you can modify headers without having to modify existing applications or filters.

Try it out!

To use configurable response headers, begin by defining a new element called headers in the server.xml. You can configure this for individual HTTP endpoints or for all endpoints at once.

To configure the headers element for an individual endpoint, specify the element inside the httpEndpoint configuration for that endpoint:

<httpEndpoint id="defaultHttpEndpoint"
                  httpPort="9080"
                  httpsPort="9443" >

       <headers>
            <add>foo:bar</add>
            <add>foo:bar2</add>
            <set>customHeader:customValue</set>
            <setIfMissing>X-Forwarded-Proto:https</setIfMissing>
            <remove>Via</remove>
       </headers>

</httpEndpoint>

To configure the headers element once to apply to multiple endpoints in your configuration, specify it as a peer of httpEndpoint and then reference it in each httpEndpoint element with the headersRef attribute:

 <httpEndpoint id="defaultHttpEndpoint"
                         httpPort="9080"
                         httpsPort="9443"
                         headersRef="myHeadersID">
     </httpEndpoint>

     <httpEndpoint id="otherHttpEndpoint"
                         httpPort="9081"
                         httpsPort="9444"
                         headersRef="myHeadersID">
    </httpEndpoint>

     <headers id="myHeadersID">
            <add>foo:bar</add>
            <add>foo:bar2</add>
            <set>customHeader:customValue</set>
            <setIfMissing>X-Forwarded-Proto:https</setIfMissing>
            <remove>Via</remove>
     </headers>

The add attribute allows multiple headers with the same name to be added to a response, similar to the HttpServletResponse’s addHeader API. Similarly, the set attribute is analogous to the setHeader API, which sets a response header to the given name and value. This overwrites existing headers that share the same name. The setIfMissing attribute sets the configured headers only if they are not already present on the response. Lastly, the remove attribute removes any response headers with a name that matches the value that is specified in the attribute.

Try it now

To try out these features, just update your build tools to pull the Open Liberty All Beta Features package instead of the main release. The beta works with Java SE 17, Java SE 11, or Java SE 8.

If you’re using Maven, here are the coordinates:

<dependency>
  <groupId>io.openliberty.beta</groupId>
  <artifactId>openliberty-runtime</artifactId>
  <version>21.0.0.11-beta</version>
  <type>pom</type>
</dependency>

Or for Gradle:

dependencies {
    libertyRuntime group: 'io.openliberty.beta', name: 'openliberty-runtime', version: '[21.0.0.11-beta,)'
}

Or take a look at our Downloads page.

Jakarta EE 9.1 Beta Features package

As documented in the release of Open Liberty 21.0.0.8-beta, the convenience features jakartaee-9.0, jakarteeClient-9.0 and webProfile-9.0 have now been deleted in Open Liberty 21.0.0.11-beta, and completely replaced by jakartaee-9.1, jakarteeClient-9.1 and webProfile-9.1.

Enable the Jakarta EE 9.1 beta features in your server.xml. You can enable the individual features you want or you can just add the Jakarta EE 9.1 convenience feature to enable all of the Jakarta EE 9.1 beta features at once:

  <featureManager>
    <feature>jakartaee-9.1</feature>
  </featureManager>

Or you can add the Web Profile convenience feature to enable all of the Jakarta EE 9.1 Web Profile beta features at once:

  <featureManager>
    <feature>webProfile-9.1</feature>
  </featureManager>

Try it now

To try out these Jakarta EE 9.1 features on Open Liberty in a lightweight package, just update your build tools to pull the Open Liberty Jakarta EE 9.1 Beta Features package instead of the main release. The beta works with Java SE 17, Java SE 11, or Java SE 8.

If you’re using Maven, here are the coordinates:

<dependency>
    <groupId>io.openliberty.beta</groupId>
    <artifactId>openliberty-jakartaee9</artifactId>
    <version>21.0.0.11-beta</version>
    <type>zip</type>
</dependency>

Or for Gradle:

dependencies {
    libertyRuntime group: 'io.openliberty.beta', name: 'openliberty-jakartaee9', version: '[21.0.0.11-beta,)'
}

Or take a look at our Downloads page.

Your feedback is welcomed

Let us know what you think on our mailing list. If you hit a problem, post a question on StackOverflow. If you hit a bug, please raise an issue.

MicroProfile, Jakarta EE and Open Liberty at JCON-Online 2021

Thu, 30 Sep 2021 00:00:00 +0000

Despite the global pandemic and general chaos of this year, many amazing developer events and conferences are still taking place virtually, bringing the developer community together once more. One such event that will use a digital format to bring together the international Java community is JCON-Online. The great part is, it’s free for all JUG (Java User Group) members!

Several members of the Open Liberty team will be joining JCON-Online 2021 on 5-8 October. If you’re also going to be there, deciding which of the great talks to see at JCON looks like it could be a challenge. So we’ve put together a helpful summary of the sessions on MicroProfile, Jakarta EE and Open Liberty.

Talks at JCON 2021

A selection of MicroProfile and Open Liberty talks on Tuesday, Wednesday and Thursday:

Tuesday 5th

Live coding: Configuring your cloud-native applications with MicroProfile Config

Java Champion Emily Jiang’s live demo session will showcase various ways to configure your microservices via the amazing features introduced in MicroProfile Config 2.0, including config profile, config properties, variable replacement and many more.

Wednesday 6th

Exploring Stateful Microservices built with Open Liberty in Kubernetes

Chicago JUG’s Mary Grygleski explores a tried and true, enterprise-grade, Java open source stack: Open Liberty in Kubernetes, a modern server solution that epitomizes all the elements needed to build, run and deploy an efficient production system today. Mary will examine and demonstrate the fundamentals of such a system that’s built with Open Liberty in Kubernetes, including: Microservices/REST API, Concurrency, Stateful vs Stateless and Deployment.
RESTful Java: 2021 edition

Open Liberty’s Andrew McCright will compare and contrast several popular Java APIs and frameworks for creating and consuming RESTful services. He’ll cover when and where some APIs make more sense than others and some basic architecture practices to facilitate porting between different frameworks.

Thursday 7th

Landscape of MicroProfile and Jakarta EE

Open Liberty’s YK Chang and Kathryn Kodama will examine the tools that are available to make your life easier as you code MicroProfile and Jakarta EE-based applications. These tools help developers throughout the development lifecycle, from creating a new application, working with compatible runtimes and your favourite editor, to testing your application.
Thriving in the cloud: Going beyond the 12 factors

In this session, Open Liberty’s Grace Jansen will dive into the extended and updated 15 factors needed to build cloud-native applications that are able to thrive in the cloud, and she’ll take a look at the open source technologies and tools that can help us achieve this.
MicroProfile 4.0 and beyond

Emily Jiang will discuss how MicroProfile has evolved to become a standard body for developing cloud-native APIs. She’ll bring you up to date with the new features in MicroProfile 4.0 with a live demo and briefly discuss what is next for this open source project. Come to this session to get yourself updated with the latest news on MicroProfile.

Workshops at JCON 2021

If you’re interested in attending the 'Big workshop day' on Friday 8th:

Cloud-Native Made easy with MicroProfile and Jakarta EE

Grace Jansen, Jamie Coleman, YK Chang and Mary Grygleski will lead this workshop where you can experience first-hand how to build cloud-native solutions quickly and efficiently with open enterprise-grade cloud-native Java programming APIs optimized for microservices and the cloud. They’ll be covering a range of topics in a hands-on manner, including: developing RESTful and reactive services, effective testing, and application considerations for cloud-native applications.
Running your Java enterprise on Open Liberty on Azure Red Hat OpenShift

Graham Charters will team up with Microsoft’s Principal Architect Edward Burns to lead this fast-paced hands-on workshop, where you’ll see first-hand how to run Java EE, Jakarta EE and MicroProfile applications on Open Liberty on Azure Red Hat OpenShift (ARO). The combination of ARO with Open Liberty offers a powerful and flexible platform for your enterprise Java applications.

Here’s a couple of talks about MicroProfile and Jakarta EE by others contributing to the these fantastic open-source projects:

Jakarta EE Core Profile: A slimmer Jakarta EE by Ivar Grimstad (Jakarta EE Developer Advocate, Eclipse Foundation)
Jakarta EE Security - Sailing Safe in Troubled Waters by Ivar Grimstad (Jakarta EE Developer Advocate, Eclipse Foundation)
A freakonomic take on open standard and Jakarta EE by Reza Rahman (Principal Program Manager, Microsoft)
Effective Kubernetes for Jakarta EE and MicroProfile Developers by Reza Rahman (Principal Program Manager, Microsoft)

And finally, for those intersted in talks in languages other than English on these topics, check out the following session in German:

Dream-Team Jakarta EE + MicroProfile by Dirk Weil (CEO, GEDOPLAN GmbH)

You can find the full schedule on the conference website.

Meet our open-source champions: Kevin Sutter, JakartaEE Advocate

Fri, 10 Sep 2021 00:00:00 +0000

Introduction:

Kevin is co-lead of both the Jakarta EE ™ Platform project and the MicroProfile ™ project at the Eclipse Foundation. His involvement with these projects started during the initial investigative phases and continues with all aspects of code and specification development – project committer, PMC member, Steering Committee member, and Specification Committee member.

Kevin’s day job is leading the architecture of Enterprise Java for the WebSphere product family at IBM. Outside of work, he enjoys the outdoors (camping, biking, hiking, skiing) and working on family construction projects.

Tech introduction:

Jakarta EE is the reincarnation of Java EE ™ in the open source world. Jakarta EE operates under an open governance model at the Eclipse Foundation. Many more organizations and individuals now contribute to the future of Java in the Enterprise via the Jakarta EE Working Group and associated Specification Projects.

MicroProfile was created to innovate Enterprise Java in a microservices environment. At the time, Java EE was stagnant and had not started its journey as Jakarta EE. A few key organizations collaborated to create MicroProfile at the Eclipse Foundation and it has continued to grow, establishing a working group earlier this year.

Due to my involvement with these two key working groups at the Foundation, I was elected as a Committer Representative to the Eclipse Foundation Board of Directors early in 2021. This participation has allowed me to meet with and participate with other leaders across the open-source industry.

What encouraged you to get started with open source projects? How does working on an open-source community project like this compare to working on a proprietary project?
How has your experience working on open-source project affected or influenced your work at IBM?
How has your role changed since getting involved in open-source? What impact have you been able to have within IBM through your role/involvement?
Why is JakartaEE an important open source project? What does it offer? How did this project come about? How did it evolve from EE4J?
What is it like to create a specification for an open-source project like this? How does it differ to working on code?
How did you become a project lead for JakartaEE? What is involved with being a project lead for an open source project like this?
As a fan of enterprise Java and its related open source projects, why would you recommend this language and its related projects for those seeking to build cloud-native enterprise applications?
What tips would you give for someone who is interested in getting involved in open source? Any specific tips for the JakartaEE or MicroProfile communities?
Now a fun question — What activities do you enjoy outside of work?

Q&A:

What encouraged you to get started with open source projects? How does working on an open-source community project like this compare to working on a proprietary project?

An IBM assignment was my first introduction to open source. Back in 2006, I was asked to lead the JPA (Java Persistence API) effort for WebSphere. This assignment required me to participate on the OpenJPA project at Apache. This was my first exposure to the open source environment. And, to be honest, I have never looked back. My "team" was no longer just IBMers. It consisted of extremely talented individuals from other companies and organizations. At first, I was nervous about "meeting the bar", but, I quickly learned that not any one person knows everything and that everyone makes mistakes. The open source community is there to help you grow in your career.

I find open-source development very enjoyable and very educational. Everyday I am working with top-notch talent across the industry. This not only keeps me on my toes, but it’s also so good to learn from this set of talented individuals.

Schedules are also a little more flexible in the open-source environment. We still set goals and deadlines. However, since this is an open-source effort, we are dependent on the time and resources available from any given organization. We still find ourselves working long hours at times, but it’s more because of our desire and commitment to completing the task rather than because an executive needs something for a customer presentation by Monday morning.

How has your experience working on open-source project affected or influenced your work at IBM?

I have learned how important the community is. When I am working with so many unique individuals and organizations across the spectrum for completing some task, you need to rely on a much bigger and varied community. Community members start to work with and educate other community members and, pretty soon, you start to get contributions from people you have never heard of before. The community just continues to grow and thrive.

How has your role changed since getting involved in open-source? What impact have you been able to have within IBM through your role/involvement?

Recently, because of my shift to a part-time FWLOA (Flexible Work Leave of Absence) schedule, my focus for my three days of work is on our open-source activities at the Eclipse Foundation. I have allocated my WebSphere product development responsibilities to other individuals. Being able to focus on open-source almost exclusively has really been beneficial to the success of my part-time schedule.

Previous to being elected as a Committer Rep on the Eclipse Foundation Board, I was the backup participant for Pradeep Balachandran (IBM’s rep on the Board). My involvement with both the Jakarta EE and MicroProfile efforts were key factors in being selected for this role. And, now being an actual member of the Board, I participate and vote on the Board’s decisions to help shape the future of the Eclipse Foundation. To me that is pretty cool!

Why is JakartaEE an important open source project? What does it offer? How did this project come about? How did it evolve from EE4J?

Java EE had an amazingly large customer base across the globe. Of course, WebSphere supported this programming model. But, so did several other companies — with either products or services in support of Java EE. Now that Java EE has completely migrated to Jakarta EE at Eclipse, we have even a larger responsibility to grow and cultivate this important programming model.

One of the big changes that was first introduced was the changing from the "javax" namespace to the "jakarta" namespace. Although this was a challenge for everyone involved, it was a necessary step to completely break away from the old "ball-and-chain" of Java EE processes and regulations. We are now able to introduce new innovative features (and possibly remove some "dead weight") to the Jakarta EE programming model. The plans for Jakarta EE 10 are really shaping up to demonstrate this new frontier.

As far as the relationship between EE4J and Jakarta EE… When Java EE was first contributed to the Eclipse Foundation, we needed a project name to use in our conversations to differentiate it from Java EE. We knew that project names with the "for Java" suffix were okay to use, so we just reversed the order of the Java EE name and came up with "EE for Java", which is abbreviated EE4J. The EE4J name is still used in some of our artifacts such as our github repository — https://github.com/eclipse-ee4j.

What is it like to create a specification for an open-source project like this? How does it differ from working on code?

Specifications can be tricky. We use the English language to describe the programming model capabilities. And, the language has to be very specific (must, should, may, …) to get the proper semantic meaning. But, code still plays a part in the Specification process. We need to codify the Specifications with the associated APIs. We also need to develop a set of Technology Compatibility Kit (TCK) tests, which are used to verify any potential Compatible Implementations. The combination of the Specification, API, TCK, and Compatible Implementation is key to the success of the Specification.

How did you become a project lead for JakartaEE? What is involved with being a project lead for an open source project like this?

A project lead for a Specification project is really not all that special. We have no more control or influence on the Specification content than any other committer or contributor to the project. To be clear, a Specification project lead is not a Specification lead, like in the old days with Java EE. A Specification project lead helps ensure that the open-source specification process is properly interpreted and followed. Each component Specification project lead also maintains communication with the Platform project to ensure that we have cohesive platform.

As a fan of enterprise Java and its related open source projects, why would you recommend this language for those seeking to build cloud-native enterprise applications?

Enterprise Java has a long history and it continues to evolve as our customers' needs evolve. Java is still near the top of programming languages in use today. And, with the introduction of MicroProfile and other new innovations in Jakarta EE, this whole environment continues to thrive. I have no hesitancy recommending the whole Java ecosystem for microservice and enterprise development efforts.

What tips would you give for someone who is interested in getting involved in open source? Any specific tips for the JakartaEE or MicroProfile communities?

Just start! Pick an area you have an interest in, whether it’s a specific technology like Servlet or MVC, or a specific skill like documentation or testing. There are so many different ways to contribute. All of the projects have mailing lists and/or GitHub repositories. Start exploring. Find some Issue that interests you and try contributing. Case in point: most of the images in our platform specification are in png format. These are extremely hard to maintain. A new contributor noticed that we were looking for svg format replacements for these images and they started to contribute replacement images. This person had an interest and skill that filled a void in our Platform team.

Now a fun question — What activities do you enjoy outside of work?

Just about anything that is "real" and not "abstract" like what we do at work everyday. I enjoy carpentry work. Recently, I helped with re-modeling the basement of my daughter’s home. This included everything from drawing up plans, getting permits, doing the plumbing, and doing the electrical. The drywall is up, so all that is left is the finish work. With their home being built in 1920, there are always projects to keep me busy.

My wife and I enjoy many activities together including camping, biking, and hiking. We are also avid (American) football fans. I’ve been a Vikings fan all my life and my wife is a diehard Packers fan, but we still get along — even after the game where the Vikings defense broke the Packers quarterback’s collarbone and ended his season (2017).

Another activity I am very involved with is the VITA (Volunteer Income Tax Assistance) tax program. This program helps low-income and elderly people in our area with completing their tax returns each year. I have learned so much about our community while assisting with this activity. And, I’ve learned much more about our tax laws than I really ever cared to… :-)

Thank you for the opportunity to share my thoughts about open-source development.

Getting started with Open Source

If this article has helped inspire you to get started contributing to open source, why not consider contributing to Open Liberty. It’s easy to get started: https://openliberty.io/contribute/

Java 17 early access support, JWE support for access and ID tokens, MicroProfile Context Propagation 1.3, and more in Open Liberty 21.0.0.10-beta

Tue, 07 Sep 2021 00:00:00 +0000

Open Liberty 21.0.0.10-beta provides long-awaited Java 17 early access support, offering a lot of new enhancements and functionality. Also included is JWE token format support for OpenID Connect Client (OIDC) and Social Media Login. This beta also offers updates to MicroProfile Context Propagation, meaning that you can now use MicroProfile Context Propagation within your Jakarta EE 9 applications, as well as Jakarta EE 9 support for the remaining Open Liberty value-add features.

We have two beta packages for Open Liberty:

All Beta Features: a larger package that contains all Open Liberty beta features (including Jakarta EE 9 beta features) and GA features and functions.
Jakarta EE 9 Beta Features: a lightweight package that contains only the Jakarta EE 9 features.

This means that you can now try out our in-development Open Liberty features by just adding the relevant coordinates to your build tools.

If you try either package, let us know what you think.

All Beta Features package

The All Beta Features package includes the following beta features:

Java 17 early access support
JWE support for OpenID Connect Client and Social Media Login
MicroProfile Context Propagation 1.3
Jakarta EE 9 support for the remaining Open Liberty value-add features

Java 17 early access support

The long awaited release of Java 17 is coming soon and it will be the first LTS (long term support) release since Java 11. It will offer a lot of new functionality and environmental changes that you will want to check into. Because it will be a milestone release, we thought you might like to take a test drive with the early access release of Java 17 (we have been testing with build 35). This will allow you to test out your existing applications and microservices or write a new one on your favorite server runtime, Open Liberty!

Some of the noteworthy highlights from Java 12-17:

By taking advantage of trying out the new changes in Java 17 now, you get more time to review your applications, microservices and runtime environments and be a step ahead when it becomes generally available.

To give this a try today, download the early access release of Java 17, download and install the 21.0.0.10-beta version of Open Liberty, edit your Liberty server’s server.env file to point JAVA_HOME to your Java 17 installation and start testing!

For more information on Java 17, please visit the Java 17 release notes page, API Javadoc page or download page. For more information on Open Liberty, please visit our documentation page.

*Note: As we work towards full Java 17 support ourselves, please excuse any of our functionality that might not be 100% ready yet. If you do hit any issues, let us know by providing feedback.

JWE support for OpenID Connect Client and Social Media Login

With this beta, the OpenID Connect Client 1.0 and Social Media Login 1.0 features support receiving tokens in the JSON Web Encryption (JWE) format. A JWE is a way to represent encrypted content using JSON. In addition to supporting JWE, the OpenID Connect Client 1.0 feature provides an option to temporarily cache access token validation results for inbound propagation. Both features add support for the RS384, RS512, HS384, HS512, ES256, ES384, and ES512 signature algorithms.

Prior to this beta, the OpenID Connect Client 1.0 and Social Media Login 1.0 features did not support consuming access or ID tokens in JWE format. This limited our interoperability with other OIDC clients and providers that use JWEs to propagate access tokens or provide identifying information about the authenticated user. With this beta, the OpenID Connect Client 1.0 and Social Media Login 1.0 features will be able to interoperate with OpenID Connect Providers that provide JWE formatted access and ID tokens.

You can configure a Liberty OpenID Connect Relying Party to process access and ID tokens that are in a JWE format. The corresponding OpenID Connect Provider should support creating JWE access or ID tokens.

Set the OpenID Connect Provider with the OpenID Connect Relying Party’s public key that is used to encrypt the Content Encryption Key according to the OpenID Connect Provider’s documentation.
Set the keyManagementKeyAlias attribute to the private key alias of the key management key that is used to decrypt the Content Encryption Key of JWE token. The key must exist in the keyStore configured for the SSL configuration referred by the the sslRef attribute. For example, <openidConnectClient keyManagementKeyAlias="privateKeyAlias" />

Optional: Configure access token cache.

You can configure a Liberty OpenID Connect Relying Party to cache access token validation results for inbound propagation.

Set the accessTokenCacheEnabled attribute to true.
Set the accessTokenCacheTimeout attribute to a duration specifying how long an authenticated subject that is created by using a propagated access token is cached.
Set the tokenReuse attribute to true if the OpenID Connect Relying Party must cache results for a JWT access token that includes a jti claim. Although enabling this support may result in a performance improvement, it is recommended that the value for the accessTokenCacheTimeout attribute is short to reduce the possibility of a stale result as compared to what a validation call to the OpenID Connect Provider would have produced.

You can also configure Liberty OIDC Social Login to process ID tokens that are in a JWE format. The corresponding OpenID Connect Provider should support creating JWE ID tokens.

Set the OpenID Connect Provider with the OIDC Social Login’s public key that is used to encrypt the Content Encryption Key according to the OpenID Connect Provider’s documentation.
Set the keyManagementKeyAlias attribute to the private key alias of the key management key that is used to decrypt the Content Encryption Key of JWE token. The key must exist in the keyStore configured for the SSL configuration referred by the the sslRef attribute. For example, <oidcLogin keyManagementKeyAlias="privateKeyAlias" />

The signatureAlgorithm attributes of both elements now support the RS384, RS512, HS384, HS512, ES256, ES384, and ES512 signature algorithms.

<openidConnectClient signatureAlgorithm="RS384"/> <oidcLogin signatureAlgorithm="RS384"/>

For more information about OpenID Connect Client refer to the OpenID Connect Client specification.

MicroProfile Context Propagation 1.3

MicroProfile Context Propagation 1.3 Release Candidate 1 adds support for Jakarta EE 9 packages (jakarta.*) and eventual alignment with the MicroProfile 5.0 platform. With the 1.3 RC1 release, you can now use MicroProfile Context Propagation within your Jakarta EE 9 applications.

To enable the new beta features in your app, add them to your server.xml:

<server>
  <featureManager>
    <feature>cdi-3.0</feature>
    <feature>jndi-1.0</feature>
    <feature>mpContextPropagation-1.3</feature>
    <feature>servlet-5.0</feature>
  </featureManager>
</server>

If you’re using Maven, here are the coordinates:

<dependency>
    <groupId>org.eclipse.microprofile.context-propagation</groupId>
    <artifactId>microprofile-context-propagation-api</artifactId>
    <version>1.3-RC1</version>
</dependency>

For more information on this MicroProfile Context Propagation update, refer to the JavaDoc and specification.

Jakarta EE 9 support for the remaining Open Liberty value-add features

In January of this year we published the Open Liberty 21.0.0.2-beta release blog post which announced Open Liberty becoming the first vendor product to be Jakarta EE Web Profile 9.0 compatible, and since then we’ve continued to deliver more Jakarta EE 9 support. This included 9.0 Full Platform support, 9.1 Web Profile and Full Platform support, and incremental support of Jakarta 9 for the Open Liberty value-add features. With the 21.0.0.10-beta release, we are proud to announce that we have now completed our journey by adding Jakarta EE 9 support for the remaining value-add features! The value-add features with Jakarta EE9 support that are added in this beta release are as follows:

Admin Center (adminCenter-1.0)
Batch Management (batchManagement-1.0)
gRPC (grpc-1.0)
gRPC Client (grpcClient-1.0)
Web Response Cache (webCache-1.0)
Web Services Atomic Transaction (wsAtomicTransaction-1.2)
Web Services Security (wsSecurity-1.1)
Web Services Security SAML (wsSecuritySaml-1.1)

Existing server configurations that use these value-add features will now work with Jakarta EE 9 features when migrating applications in those server configuration to use Jakarta EE9 technologies.

Next on the horizon is MicroProfile 5.0, which will bring Jakarta EE 9 support to the various MicroProfile features.

Try it now

To try out these features, just update your build tools to pull the Open Liberty All Beta Features package instead of the main release. The beta works with Java SE 15, Java SE 11, or Java SE 8.

If you’re using Maven, here are the coordinates:

<dependency>
  <groupId>io.openliberty.beta</groupId>
  <artifactId>openliberty-runtime</artifactId>
  <version>20.0.0.10-beta</version>
  <type>pom</type>
</dependency>

Or for Gradle:

dependencies {
    libertyRuntime group: 'io.openliberty.beta', name: 'openliberty-runtime', version: '[20.0.0.10-beta,)'
}

Or take a look at our Downloads page.

Jakarta EE 9 Beta Features package

Open Liberty is the first vendor product to be Jakarta EE Web Profile 9.0 compatible since the 21.0.0.2-beta release. Open Liberty is also the first vendor product to be added to the Jakarta EE Platform 9.0 compatability list, with the release of 21.0.0.3-beta. Open Liberty 21.0.0.6-beta further expanded on this compatability by including new Jakarta EE9 supporting features, and 21.0.0.10-beta offers the same compatability with Jakarta EE9 with performance enhancements.

  <featureManager>
    <feature>jakartaee-9.0</feature>
  </featureManager>

Or you can add the Web Profile convenience feature to enable all of the Jakarta EE 9 Web Profile beta features at once:

  <featureManager>
    <feature>webProfile-9.0</feature>
  </featureManager>

Try it now

If you’re using Maven, here are the coordinates:

<dependency>
    <groupId>io.openliberty.beta</groupId>
    <artifactId>openliberty-jakartaee9</artifactId>
    <version>20.0.0.10-beta</version>
    <type>zip</type>
</dependency>

Or for Gradle:

dependencies {
    libertyRuntime group: 'io.openliberty.beta', name: 'openliberty-jakartaee9', version: '[20.0.0.10-beta,)'
}

Or take a look at our Downloads page.

Your feedback is welcomed

Let us know what you think on our mailing list. If you hit a problem, post a question on StackOverflow. If you hit a bug, please raise an issue.

Introducing the Open Liberty Starter!

Fri, 20 Aug 2021 00:00:00 +0000

Open Liberty Starter

There is now another easy way to get started with Open Liberty. Visit the Getting Started page and select a few options to generate a starter application that runs on Open Liberty. You can specify your application and project name, choose a build tool from either Maven or Gradle, and pick which version of Java SE, Jakarta EE, and MicroProfile your application will use. Then, just click Generate Project and you are ready for lift-off!

What is the starter?

The Open Liberty starter gives you a simple, quick way to get the necessary files to start building an application on Open Liberty. There is no need to search how to find out what to add to your maven or gradle build files. A simple RestApplication.java file is generated for you to start creating a REST based application. A server.xml configuration file is provided with the necessary features for the MicroProfile and Jakarta EE versions that you previously selected.

If you plan on developing and/or deploying your app in a containerized environment, the included Dockerfile will make it easier to create your application image on top of the Open Liberty Docker image.

Once you download the starter project, unpackage the .zip file on your machine.

If you selected Maven as your build tool, then open a command line session, navigate to the installation directory, and run mvnw liberty:run. This will install all required dependencies and start the default server. If successful, you will see the necessary features installed and the message "server is ready to run a smarter planet."

A starter project using Maven is generated for you with the following files:

If you selected Gradle as your build tool, then open a command line session, navigate to the installation directory, and run gradlew libertyStart to start the default server. If successful, you will see the necessary features installed from the installFeature task and the message "server is ready to run a smarter planet."

A starter project using Gradle is generated for you with the following files:

For more information on developing your application in dev mode using either Maven or Gradle, see the dev mode documentation.

For further help on getting started actually developing your application, see some of our Microprofile guides and Jakarta EE guides.

Other ways to start using Open Liberty

There are a few other ways to get started with Open Liberty if you prefer instead:

Docker image

You can pull in the official Open Liberty docker image from Docker Hub and build your application image on top of the Open Liberty image. For more information, see our guide on using Docker with Open Liberty, Using Docker containers to develop microservices.

Maven

You can also use Maven to pull in Open Liberty as a dependency for your application. To get started using Open Liberty with Maven, add the following to your pom.xml, while specifying the version of Open Liberty that you want to use:

<dependency>
    <groupId>io.openliberty</groupId>
    <artifactId>openliberty-runtime</artifactId>
    <version>[21.0.0.8,)</version>
    <type>zip</type>
</dependency>

For more information on using Open Liberty and Maven, visit our Maven Intro Guide.

Gradle

You can also use Gradle to pull in Open Liberty as a dependency for your application. To get started using Open Liberty with Gradle, add the following to build.gradle, while specifying the version of Open Liberty that you want to use:

dependencies {
    libertyRuntime group: 'io.openliberty', name: 'openliberty-runtime', version: '[21.0.0.8,)'
}

For more information on using Open Liberty and Gradle, visit our Gradle Intro Guide.

Open Liberty Binary Package

Download an Open Liberty release from our Getting Started page and extract the package. Then navigate to the bin directory and execute the server create <server_name> command to create an Open Liberty server, or run the server start command to automatically create and start a defaultServer. Then, you can add in your application to the dropins directory, or add the path to your application in the newly created <path_to_Open_Liberty_install>/servers/<server_name>/server.xml.

For more information regarding Liberty commands and configuration, visit the Command overview and Server configuration overview docs.

Endpoint activation monitoring and more now available on Open Liberty 21.0.0.9-beta

Fri, 06 Aug 2021 00:00:00 +0000

Open Liberty 21.0.0.9-beta offers exciting new enhancements for Liberty embedders such as endpoint activation monitoring to determine when endpoints are available to use.

We have two beta packages for Open Liberty:

All Beta Features: a larger package that contains all Open Liberty beta features (including Jakarta EE 9 beta features) and GA features and functions.
Jakarta EE 9 Beta Features: a lightweight package that contains only the Jakarta EE 9 features.

This means that you can now try out our in-development Open Liberty features by just adding the relevant coordinates to your build tools.

If you try either package, let us know what you think.

All Beta Features package

The All Beta Features package includes the following beta features:

New method to determine active endpoints
MicroProfile 4.1

New method to determine active endpoints

The ServerEndpointControlMBean can currently be used to pause and resume endpoints, including HTTP and messaging ports. It can also determine if an endpoint is currently paused. However, there is no way to determine programmatically if an endpoint exists and is active. This update provides a new method on the mbean, isActive, that will determine if an endpoint exists, has started, and is not paused. A new method was added to the ServerEndpointControlMBean:

public boolean isActive(String targets);

The targets parameter is a comma separated list of endpoint names.

This mirrors the existing isPaused method. It will return true only if all of the endpoints listed exist, are started, and are not paused.

// Check if the defaultHttpEndpoint is active
boolean isEndpointActive = mbean.isActive("defaultHttpEndpoint");

For more information about ServerEndpointControlMBean methods, refer to the API documentation.

Try it now

To try out these features, just update your build tools to pull the Open Liberty All Beta Features package instead of the main release. The beta works with Java SE 15, Java SE 11, or Java SE 8.

If you’re using Maven, here are the coordinates:

<dependency>
  <groupId>io.openliberty.beta</groupId>
  <artifactId>openliberty-runtime</artifactId>
  <version>21.0.0.9-beta</version>
  <type>pom</type>
</dependency>

Or for Gradle:

dependencies {
    libertyRuntime group: 'io.openliberty.beta', name: 'openliberty-runtime', version: '[21.0.0.9-beta,)'
}

Or take a look at our Downloads page.

MicroProfile 4.1 Beta Features

MicroProfile 4.1 was originally released in the Open Liberty Beta 21.0.0.8-beta and it is also in this beta. More information on MicroProfile 4.1 is available here.

Jakarta EE 9 Beta Features package

Open Liberty is the first vendor product to be Jakarta EE Web Profile 9.0 compatible since the 21.0.0.2-beta release. Open Liberty is also the first vendor product to be added to the Jakarta EE Platform 9.0 compatability list, with the release of 21.0.0.3-beta. Open Liberty 21.0.0.6-beta further expanded on this compatability by including new Jakarta EE9 supporting features, and 21.0.0.9-beta offers the same compatability with Jakarta EE9 with performance enhancements.

  <featureManager>
    <feature>jakartaee-9.0</feature>
  </featureManager>

Or you can add the Web Profile convenience feature to enable all of the Jakarta EE 9 Web Profile beta features at once:

  <featureManager>
    <feature>webProfile-9.0</feature>
  </featureManager>

Try it now

If you’re using Maven, here are the coordinates:

<dependency>
    <groupId>io.openliberty.beta</groupId>
    <artifactId>openliberty-jakartaee9</artifactId>
    <version>21.0.0.9-beta</version>
    <type>zip</type>
</dependency>

Or for Gradle:

dependencies {
    libertyRuntime group: 'io.openliberty.beta', name: 'openliberty-jakartaee9', version: '[20.0.0.9-beta,)'
}

Or take a look at our Downloads page.

Your feedback is welcomed

Let us know what you think on our mailing list. If you hit a problem, post a question on StackOverflow. If you hit a bug, please raise an issue.

MicroProfile 4.1 plus more exciting features now in Open Liberty 21.0.0.8-beta

Mon, 12 Jul 2021 00:00:00 +0000

Open Liberty 21.0.0.8-beta introduces MicroProfile 4.1 with updates to the MicroProfile Health feature. A new logging format (TBASIC) is made available. The Stale Connection Identification feature makes it possible to provide additional configuration for a data source. A couple of Jakarta EE 9.1 convenience features are also included in the "All Beta" package.

We have two beta packages for Open Liberty:

All Beta Features: a larger package that contains all Open Liberty beta features (including Jakarta EE 9 beta features) and GA features and functions.
Jakarta EE 9 Beta Features: a lightweight package that contains only the Jakarta EE 9 features.

This means that you can now try out our in-development Open Liberty features by just adding the relevant coordinates to your build tools.

If you try one of these packages, let us know what you think.

All Beta Features package

The All Beta Features package includes the following beta features:

MicroProfile Updates
- MicroProfile 4.1
- MicroProfile Health 3.1
TBASIC Logging Format Beta
Customizing Stale Connection Identification
Jakarta EE 9.1 convenience features

Try it now

MicroProfile Updates

In Open Liberty 21.0.0.8-beta we have two updates: MicroProfile 4.1 improves developer experience with updates to the Health feature; MicroProfile Health 3.1 enables you to provide your own Startup health check procedures to be invoked by Open Liberty. Find out more below.

MicroProfile 4.1

MicroProfile 4.1 improves developer experience with updates to the Health feature. MicroProfile 4.1 also defines compatible implementation requirements for runtimes, which must pass all of the MicroProfile component specification TCKs including Config 2.0, Fault Tolerance 3.0, Rest Client 2.0, Health 3.1, Metrics 3.0, Open Tracing 2.0, Open API 2.0, and JWT propagation 1.2. This beta driver will be used as a compatible implementation for releasing MicroProfile 4.1.

<featureManager>
    <feature>microProfile-4.1</feature>
</featureManager>

To find out more take a look at the MicroProfile 4.1 Release.

MicroProfile Health 3.1

MicroProfile Health enables you to provide your own health check procedures to be invoked by Open Liberty, to verify the health of your microservice. A service checks its own health by performing necessary self-checks and then reports its overall status by implementing the API provided by MicroProfile Health. A self-check can be a check on anything that the service needs, such as a dependency, a successful connection to an endpoint, a system property, a database connection, or the availability of required resources. MicroProfile offers checks for both Liveness and Readiness. MicroProfile Health 3.1 introduces a new Health Check called Startup, which allows applications to define startup probes that are used for initial verification of the application before the Liveness probe takes over. This is useful for applications which require additional startup time on their first initialization.

In the previous versions of MicroProfile Health, there were no unique APIs or endpoints to distinguish the start up status of your microservices. MicroProfile Health 3.1 introduces a new convenient @Startup annotation to create your own health check procedures to verify that your microservices have fully initialized. The status of the Startup health checks of your microservices can be viewed with the new REST endpoint /health/started. You can now configure the Kubernetes Startup probe with this new endpoint as well. In Open Liberty, you can use the Startup endpoint, /health/started, to verify if your deployed applications have started or not.

When deployed application(s) are not started yet, the overall default Startup status will be DOWN, with an empty payload response until all the deployed application(s) have started. A new MicroProfile Config property (mp.health.default.startup.empty.response=UP) is available to change the overall default Startup check status to UP, during application start up.

Applications are expected to provide health check procedures by implementing the HealthCheck interface with the @Startup, @Liveness, or @readiness annotations. These are used by Open Liberty to verify the respective Startup, Liveness, or Readiness of the application. Add the logic of your health check in the call() method, and return the HealthCheckResponse object, by using the simple up()/down() methods from the API:

**Startup Check**
@Startup
@ApplicationScoped
public class StartupMemUsageCheck implements HealthCheck {
...
    @Override
     public HealthCheckResponse call() {
       ...
       if (getMemUsage() < 0.95) {
           return HealthCheckResponse.up("memUsage");
       }
       return HealthCheckResponse.down("memUsage");
       ...
     }
}

To view the status of each health check, access the http://<hostname>:<port>/health/started endpoint.

To enable the new beta features in your app, add them to your server.xml:

<feature>mpHealth-3.1</feature>

To find out more viist:

TBASIC Logging Format

A new logging format, TBASIC, is added to match the Websphere Application Server basic logging format. This new format option can be used for consoleFormat, messageFormat, or traceFormat. TBASIC format matches the existing trace BASIC format (so now either TBASIC or BASIC can be used to refer to this format for trace). Using this new format option will allow users that utilize log parsers that work with the Websphere Application Server basic format to use the same parsers with Open Liberty logs.

The new options can be used in the bootstrap.properties file:

com.ibm.ws.logging.message.format=tbasic
com.ibm.ws.logging.console.format=tbasic
com.ibm.ws.logging.trace.format=tbasic

You can also change the format by editing the server.env and adding the following lines:

WLP_LOGGING_MESSAGE_FORMAT=TBASIC
WLP_LOGGING_CONSOLE_FORMAT=TBASIC

TBASIC Logs Example:

[24/03/21 15:04:10:331 EDT] 00000001 FrameworkMana A   CWWKE0001I: The server defaultServer has been launched.
[24/03/21 15:04:11:338 EDT] 00000001 FrameworkMana I   CWWKE0002I: The kernel started after 1.177 seconds
[24/03/21 15:04:11:465 EDT] 0000003e FeatureManage I   CWWKF0007I: Feature update started.
[24/03/21 15:04:11:635 EDT] 00000033 DropinMonitor A   CWWKZ0058I: Monitoring dropins for applications.

Customizing Stale Connection Identification

Open Liberty maintains a pool of JDBC connections to improve performance. It is necessary for Open Liberty to be able to identify when connections have become stale and are no longer usable so that such connections can be removed from the pool. Open Liberty leverages multiple standards made available by the JDBC and SQL specifications, as well as relying on some built-in knowledge of vendor-specific behavior for some JDBC drivers in order to achieve this.

Not all JDBC drivers completely follow the JDBC/SQL specifications in identifying stale connections. If you are using such a JDBC driver, it is now possible for you to provide additional configuration for a data source that helps identify the vendor-specific SQL states and error codes that are raised by the JDBC driver, enabling Liberty to better maintain the connection pool.

Configure one or more <identifyException> subelements under <dataSource> to provide the SQLException identification detail.

<featureManager>
  <feature>jdbc-4.2</feature>
  <feature>jndi-1.0</feature>
  ... other features
</featureManager>

<dataSource id="DefaultDataSource" jndiName="jdbc/myDataSource">
    <jdbcDriver libraryRef="myJDBCLib"/>
    <properties databaseName="TESTDB" serverName="localhost" portNumber="1234"/>
    <!-- identify the following as stale connections, -->
    <identifyException sqlState="08000" as="StaleConnection"/>
    <identifyException errorCode="2468" as="StaleConnection"/>
    <!-- remove built-in identification of SQL state S1000 -->
    <identifyException sqlState="S1000" as="None"/>
</dataSource>

<library id="myJDBCLib">
    <file name="C:/drivers/some-jdbc-driver.jar"/>
</library>

Jakarta EE 9.1 convenience features

Jakarta EE 9.1 convenience features are included in this beta release in the "all beta" zip file, but not yet in the Jakarta EE 9 beta zip file. The 9.1 convenience features are duplicates of the Jakarta EE 9.0 convenience features. In a future beta release, the 9.0 convenience features will be removed and only the 9.1 ones will remain. Users of the Jakarta EE 9 convenience features should look to transition to use 9.1 in preparation of 9.0 being removed.

To enable the Jakarta EE 9.1 convenience features, add them to your server.xml or client.xml:

<featureManager>
    <feature>webProfile-9.1</feature>
</featureManager>

<featureManager>
    <feature>jakartaee-9.1</feature>
</featureManager>

<featureManager>
    <feature>jakartaeeClient-9.1</feature>
</featureManager>

Try it now

To try out these features, just update your build tools to pull the Open Liberty All Beta Features package instead of the main release. The beta works with Java SE 15, Java SE 11, or Java SE 8.

If you’re using Maven, here are the coordinates:

<dependency>
  <groupId>io.openliberty.beta</groupId>
  <artifactId>openliberty-runtime</artifactId>
  <version>21.0.0.8-beta</version>
  <type>pom</type>
</dependency>

Or for Gradle:

dependencies {
    libertyRuntime group: 'io.openliberty.beta', name: 'openliberty-runtime', version: '[20.0.0.8-beta,)'
}

Or take a look at our Downloads page.

Jakarta EE 9 Beta Features package

Open Liberty 21.0.0.2-beta was the first vendor product to be Jakarta EE Web Profile 9.0 compatible. Similarly, Open Liberty 21.0.0.3-beta was the first vendor product to be added to the Jakarta EE Platform 9.0 compatibility list.. Open Liberty 21.0.0.8-beta maintains that compatibility while continuing to make quality and performance enhancements.

Try it now

If you’re using Maven, here are the coordinates:

<dependency>
    <groupId>io.openliberty.beta</groupId>
    <artifactId>openliberty-jakartaee9</artifactId>
    <version>21.0.0.8-beta</version>
    <type>zip</type>
</dependency>

Or for Gradle:

dependencies {
    libertyRuntime group: 'io.openliberty.beta', name: 'openliberty-jakartaee9', version: '[21.0.0.8-beta,)'
}

Or take a look at our Downloads page.

Your feedback is welcomed

Let us know what you think on our mailing list. If you hit a problem, post a question on StackOverflow. If you hit a bug, please raise an issue.

Open Liberty beta is Jakarta EE 9.1 compatible

Wed, 26 May 2021 00:00:00 +0000

This blog post serves as a follow-up to my last blog post about Open Liberty’s support of Jakarta EE 9.0. Over the last several months, the Jakarta EE community has updated the Jakarta EE 9 TCK to enable it to use either Java SE 8 or Java SE 11. This new version of the TCK was the bulk of the work required to complete the Jakarta EE 9.1 specification. Java SE 11 support in the TCK makes it possible to validate whether an application server that uses Java SE 11 is compatible with the Jakarta EE 9 specification.

The Jakarta EE 9.1 specification was made available this week. On day one of this new release, Open Liberty is one of the vendor implementations used to ratify the specification. The Open Liberty product is compatible for both the Jakarta EE 9.1 Web Profile and Platform specifications using both Java SE 8 and Java SE 11. What is most notable is that Open Liberty was ahead of the curve for Jakarta EE 9.1. The Open Liberty beta version that was tested with the 9.1 TCK is the same version that was marked compatible for the Jakarta EE 9.0 specification. As I stated in my previous blog post, Jakarta EE 9.1 support was anticipated due to Open Liberty’s support of Java SE 11 for over two years.

Since my last blog post, more resources are available to help you make the transition to Jakarta EE 9. A blog post with detailed instructions on using the Eclipse Transformer was created a few months ago to help guide you when updating your applications to work with Jakarta EE 9. Also, this presentation provides more details about Jakarta EE 9 and Open Liberty, including a live demo of using the Eclipse Transformer to update your applications and server configurations without doing any manual changes to source or configuration.

Testing Jakarta EE 9 Applications with Arquillian and Open Liberty

Fri, 21 May 2021 00:00:00 +0000

Request Timing Metrics and new Jakarta EE9 support in Open Liberty 21.0.0.6-beta

Tue, 18 May 2021 00:00:00 +0000

Open Liberty 21.0.0.6-beta brings improvements to the MicroProfile Metrics feature, allowing for information gathered via the Request Timing feature to be displayed on the metrics endpoint. Also included are a number of new Jakarta EE9 supporting features, including OAuth/SSO authorization and automatic certificate management.

We have two beta packages for Open Liberty:

All Beta Features: a larger package that contains all Open Liberty beta features (including Jakarta EE 9 beta features) and GA features and functions.
Jakarta EE 9 Beta Features: a lightweight package that contains only the Jakarta EE 9 features.

This means that you can now try out our in-development Open Liberty features by just adding the relevant coordinates to your build tools.

If you try either package, let us know what you think.

All Beta Features package

The All Beta Features package includes the following beta features:

Request Timing now supported by MicroProfile Metrics

Request Timing now supported by MicroProfile Metrics

The request timing feature (requestTiming-1.0) is used to keep track of the slow and hung requests for servlet requests with a RequestTimingStats MXBean. The Microprofile Metrics features (mpMetrics-X.X) on the other hand provides vendor metrics that are distinct to the Open Liberty runtime.

Starting with the Open Liberty 21.0.0.6-beta the RequestTimingStats MXBean will now have it’s data retrieved by the MicroProfile Metrics feature for reporting on the /metrics (or /metrics/vendor) endpoint. This functionality is compatible with both the 2.X and 3.X MicroProfile Metrics features.

Below is a sample output of the new request timing metrics:

# TYPE vendor_requestTiming_activeRequestCount gauge
# HELP vendor_requestTiming_activeRequestCount The number of servlet requests currently running.
vendor_requestTiming_activeRequestCount 1

# TYPE vendor_requestTiming_requestCount_total counter
# HELP vendor_requestTiming_requestCount_total The number of servlet requests since the server started.
vendor_requestTiming_requestCount_total 3

# TYPE vendor_requestTiming_hungRequestCount gauge
# HELP vendor_requestTiming_hungRequestCount The number of servlet requests that are currently running but are hung.
vendor_requestTiming_hungRequestCount 0

# TYPE vendor_requestTiming_slowRequestCount gauge
# HELP vendor_requestTiming_slowRequestCount The number of servlet requests that are currently running but are slow.
vendor_requestTiming_slowRequestCount 0

To be able to retrieve request timing metrics from /metrics you will need to enable both the requestTiming-1.0 feature in combination with one of the following MicroProfile Metric features: mpMetrics-2.0, mpMetrics-2.2 or mpMetrics-2.3 or mpMetric-3.0.

To begin recieving metrics you will need to configure the request timing thresholds for slow or hung requests. The following example demonstrates enabling request timing metrics for mpMetrics-3.0, with a sample threshold configuration for both slow and hung servlet requests.

    <featureManager>
      <feature>mpMetrics-3.0</feature>
      <feature>requestTiming-1.0</feature>
      <!-- other features omitted for brevity -->
    </featureManager>

    <requestTiming sampleRate="1" slowRequestThreshold="10s">
      <servletTiming
        slowRequestThreshold="2s"
        hungRequestThreshold="10s"/>
    </requestTiming>

For more information regarding Request Timing with MicroProfile Metrics:

Try it now

To try out these features, just update your build tools to pull the Open Liberty All Beta Features package instead of the main release. The beta works with Java SE 16, Java SE 11, or Java SE 8.

If you’re using Maven, here are the coordinates:

<dependency>
  <groupId>io.openliberty.beta</groupId>
  <artifactId>openliberty-runtime</artifactId>
  <version>21.0.0.6-beta</version>
  <type>pom</type>
</dependency>

Or for Gradle:

dependencies {
    libertyRuntime group: 'io.openliberty.beta', name: 'openliberty-runtime', version: '[21.0.0.6-beta,)'
}

Or take a look at our Downloads page.

Jakarta EE 9 Beta Features package

As of the 21.0.0.2-beta release, Open Liberty is the first vendor product to be Jakarta EE Web Profile 9.0 compatible. With the Open Liberty 21.0.0.3-beta release, Open Liberty is the first vendor product to be added to the Jakarta EE Platform 9.0 compatibility list.

This Open Liberty beta introduces the following Jakarta EE 9 features which now possess their all-new Jakarta EE 9 package names:

OpenID Connect Client 1.0 (openidConnectClient-1.0)
OpenID Connect Provider 1.0 (openidConnectServer-1.0)
Social Media Login 1.0 (socialLogin-1.0)
Automatic Certificate Management Environment (ACME) Support 2.0 (acmeCA-2.0)

The openidConnectClient-1.0, openidConnectServer-1.0, socialLogin-1.0 and acmeCA-2.0 features will automatically adapt to the level of Java EE or Jakarta EE that is already in use, so no change is needed when using them with Jakarta EE 9.

  <featureManager>
    <feature>jakartaee-9.0</feature>
  </featureManager>

Or you can add the Web Profile convenience feature to enable all of the Jakarta EE 9 Web Profile beta features at once:

  <featureManager>
    <feature>webProfile-9.0</feature>
  </featureManager>

Try it now

If you’re using Maven, here are the coordinates:

<dependency>
    <groupId>io.openliberty.beta</groupId>
    <artifactId>openliberty-jakartaee9</artifactId>
    <version>21.0.0.6-beta</version>
    <type>zip</type>
</dependency>

Or for Gradle:

dependencies {
    libertyRuntime group: 'io.openliberty.beta', name: 'openliberty-jakartaee9', version: '[21.0.0.6-beta,)'
}

Or take a look at our Downloads page.

Your feedback is welcomed

Let us know what you think on our mailing list. If you hit a problem, post a question on StackOverflow. If you hit a bug, please raise an issue.

LDAP user registry authentication and JAX-RS multipart payloads new in Open Liberty 21.0.0.5

Fri, 14 May 2021 00:00:00 +0000

Open Liberty 21.0.0.5 comes complete with a new Kerberos authentication method, allowing for the use of an LDAP user registry to easily and quickly authorize connections originating from the same source. Also included is the ability to create and exchange multipart payloads using JAX-RS clients and services.

In Open Liberty 21.0.0.5:

LDAP connection support for Kerberos authentication
Build multipart payloads for your JAX-RS client and services

View the list of fixed bugs in 21.0.0.5.

Run your apps using 21.0.0.5

If you’re using Maven, here are the coordinates:

<dependency>
    <groupId>io.openliberty</groupId>
    <artifactId>openliberty-runtime</artifactId>
    <version>21.0.0.5</version>
    <type>zip</type>
</dependency>

Or for Gradle:

dependencies {
    libertyRuntime group: 'io.openliberty', name: 'openliberty-runtime', version: '[21.0.0.5,)'
}

Or if you’re using Docker:

FROM open-liberty

Or take a look at our Downloads page.

LDAP connection support for Kerberos authentication

LDAP bind operations are used to authenticate clients (and the users or applications behind them) to the directory server. This establishes an authorization identity that is used for subsequent operations that are processed on that connection, and specifies the LDAP protocol version that the client uses. Before this update, the LdapRegistry element supported binding either anonymously or by using simple authentication with a user (bindDN) and password (bindPassword). This update adds an option to bind to LDAP: GSSAPI/Kerberos. Kerberos is an authentication mechanism that allows a client and service to mutually authenticate by a Key Distribution Center (KDC). In Open Liberty 21.0.0.5, you can use either a Kerberos credential cache (ccache) or a Kerberos keytab file.

To update an LdapRegistry to use the GSSAPI/Kerberos option, you can set the bind authentication mechanism type using the new LdapRegistry attribute, bindAuthMechanism:

bindAuthMechanism="GSSAPI"

You also need the Kerberos principal or Service Principal Name:

krb5Principal="user1@EXAMPLE.COM"

If you are using a Kerberos credential cache (ticket cache or ccache) to store the Kerberos credentials, add the ticket cache file name to the LdapRegistry with the new attribute, krb5TicketCache:

krb5TicketCache="${server.config.dir}/security/krb5-user1.cc"

If you are using a custom Kerberos configuration file (krb.conf or krb.ini), set the file name using the global Kerberos configuration element:

<kerberos configFile="${server.config.dir}/security/krb5.conf"/>

If you are using a Kerberos keytab file to store encrypted keys for principals, set the file using the global Kerberos configuration element:

<kerberos keytab="${server.config.dir}/security/krb5.keytab" configFile="${server.config.dir}/security/krb5.conf"/>

If the Kerberos configuration file is not defined, Open Liberty will attempt to resolve by using the JDK default locations and the operating system default locations.

For the Kerberos credentials, the locations are checked in the following order: the ticket cache (if provided), the configured keytab file, and finally the JDK default location.

The following example shows how to configure the LdapRegistry element using a ticket cache and custom Kerberos config file:

<kerberos keytab="${server.config.dir}/security/krb5.keytab" configFile="${server.config.dir}/security/krb5.conf"/>

<ldapRegistry id="LDAP" realm="SampleLdapADRealm" host="ldap_hostname" port="389" ignoreCase="true" baseDN="DC=example,DC=com" bindAuthMechanism="GSSAPI" krb5Principal="user1@EXAMPLE.COM" krb5TicketCache="${server.config.dir}/security/krb5-user1.cc" ldapType="Custom" />

The following example shows how to configure an LDAP Registry using a keytab and custom Kerberos config file:

<kerberos keytab="${server.config.dir}/security/krb5.keytab" configFile="${server.config.dir}/security/krb5.conf" />

<ldapRegistry id="LDAP" realm="SampleLdapADRealm" host="ldap_hostname" port="389" ignoreCase="true" baseDN="DC=example,DC=com" bindAuthMechanism="GSSAPI" krb5Principal="user1@EXAMPLE.COM" ldapType="Custom" />

For more information on LdapRegistry, see the LDAP User Registry documentation.

To enable this new function in your app, add the LDAP User Registry 3.0 feature to your server.xml file:

<featureManager>
  <feature>ldapRegistry-3.0</feature>
</featureManager>

Build multipart payloads for your JAX-RS client and services

Often, a RESTful service or client will need to send multiple disparate pieces of data in the same request, for example, uploading a resume/CV with a picture and text for name and address. This is usually done using multipart/form-data.

While Liberty currently has APIs to enable users to receive multipart/form-data payloads, it does not have any APIs to enable users to send multipart payloads - until now. With the new AttachmentBuilder API, users can now send multipart requests from their JAX-RS clients or send multipart payloads as responses from their JAX-RS resources.

To send a multipart request, you will need to enable the jaxrs-2.0 or jaxrs-2.1 feature. Presumably, if you are already using JAX-RS, one of these features will already be enabled. To send a multipart payload, you must send an instance of List<IAttachment>. Each object in that list represents a single attachment part. Here is an example of creating and sending a multipart request from a JAX-RS client:

List<IAttachment> attachments = new ArrayList<>();

attachments.add(AttachmentBuilder.newBuilder("blogPost")
                                 .inputStream(new FileInputStream("/path/to/yesterdaysBlogPost.xml"))
                                 .fileName("myRenamedBlogPost.asciidoc")
                                 .contentType("text/asciidoc")
                                 .contentId("myBlogPostID")
                                 .header("X-PriorityLevel", "Medium")
                                 .build());

attachments.add(AttachmentBuilder.newBuilder("file1")
                                 .inputStream("some.xml", new FileInputStream("/path/to/myPicture.png"))
                                 .contentType("image/png")
                                 .build());

attachments.add(AttachmentBuilder.newBuilder("authorName")
                                 .inputStream(new ByteArrayInputStream("John Doe".getBytes()))
                                 .build());

Response response = client.target(BLOG_SITE_URI)
                          .request()
                          .post(Entity.entity(attachments, MediaType.MULTIPART_FORM_DATA));

For more information vist:

multipart/form-data RFC 7578

Notable bugs fixed in this release

We’ve spent some time fixing bugs. The following sections describe just some of the issues resolved in this release. If you’re interested, here’s the full list of bugs fixed in 21.0.0.5.

Application context path can not end with a slash

Within Open Liberty you are able to retrieve the current context path by calling ServletContext.getContextPath(), the Jakarta EE specification states that this method should return a string that begins with a / character and does not end with a / character. Prior to Open Liberty 21.0.0.5, it was possible for this method to return a context root with a / appended to it, this behaviour has been corrected and will now always remove any trailing / characters.
JDBC kerberos problems on IBM JDK 8

With the release of Open Liberty 21.0.0.5 the following issues have been resolved when using JDBC kerberos with an IBM Java 8 installation:
- Fixed needing to use a file:/ URL pattern for keytab and ccache files.
- Fixed incorrectly identifying when a password is set.
- Fixed various problems related to interactive vs non-interactive modes.
- Fixed Received fatal alert: protocol_version error.
Ensure MP Config properties from the application are visible when mpOpenApi-2.0 runs filters

When using mpOpenApi-2.0, OpenAPI filters can look up MicroProfile Config values from a microprofile-config.properties file included in the application. Previously this functionality did not work and MicroProfile Config would erroneously report that the configuration property did not exist. This behaviour has been corrected and OpenAPI filters will now function as expected.
Correct the synchronization when mpOpenApi-2.0 processes applications

Prior to the release of Open Liberty 21.0.0.5, when using mpOpenApi-2.0, starting two applications concurrently could occasionally produce a number of errors and ultimately OpenAPI documentation may not be created correctly for either application. This behaviour has now been corrected and OpenAPI documentation will be created for one of the applications.

For more information visit the MicroProfile OpenAPI documentation

Get Open Liberty 21.0.0.5 now

Available through Maven, Gradle, Docker, and as a downloadable archive.

Faster startup in Open Liberty dev mode with Eclipse OpenJ9 0.26.0

Fri, 30 Apr 2021 00:00:00 +0000

The 0.26.0 release of Eclipse OpenJ9 includes updates that improve startup times for Open Liberty servers that run in development mode. This post looks at the changes behind those improvements and how you can take advantage of them.

Open Liberty development mode, or dev mode, enhances the developer experience by providing hot reload and deployment, on-demand testing, and debugger support. OpenJ9 is a scalable, high-performance, Java virtual machine (JVM) implementation. One of the biggest benefits of OpenJ9 is fast startup, thanks to the Shared Classes Cache (SCC) feature, which contains both classes and previously (dynamically) compiled Ahead-of-time (AOT) Code. AOT Compilation in OpenJ9 is the process of compiling code in one JVM instance to reuse it in another JVM instance. When you use a Java SDK with the OpenJ9 VM to run Open Liberty, the VM feature that enables dev mode is called Full Speed Debug (FSD). Before OpenJ9 version 0.26.0, the VM did not have AOT support for FSD. Therefore, Open Liberty dev mode did not benefit from the fast startup that normally comes with OpenJ9. However, from version 0.26.0 onward, FSD support is added for AOT compilations, and Open Liberty dev mode gets a boost in startup time from the SCC.

How did this improvement occur? First, a significant improvement was made in FSD performance when FSD is implemented with another feature known as OSR. This new implementation naturally facilitated generalization to relocatable compilations. The main idea behind FSD is, if a debug event occurs, an application thread moves from the middle of a compiled body to the interpreter. This transition ensures that compiled code can be highly optimized because the compiler does not need to worry about the consequences of debug events. When no more debug events exist, the application thread is allowed to run compiled code again.

Adding AOT support boiled down to ensuring that all the OSR data in the compiled body’s metadata and any breakpoint guards can be relocated^[1]^[2]^[3]. The OSR data is needed to ensure the transition from the compiled code into the interpreter. The breakpoint guards are needed to ensure that debug events are respected when a method gets inlined. Other subtleties are involved regarding relocations, which you can read about in the previously cited pull requests. However, the practical impact of these changes is a noticeable difference in the user experience of dev mode.

To give a more objective description of the improvement, I ran dev mode on the DayTrader7 benchmark application and I observed that the startup time was roughly halved. I measured this improvement by starting and stopping an Open Liberty server that was running on 4CPUs, without measuring the startup time for the first run. The first time dev mode runs with OpenJ9 0.26.0, it seems slower because the first run generates all the AOT code that is placed in the SCC. All subsequent invocations of dev mode are noticeably faster.

To conclude, I recommend upgrading your Java SDK to use OpenJ9 0.26.0 so you too can benefit from a drastic improvement in Open Liberty dev mode performance with OpenJ9.

1. https://github.com/eclipse-openj9/openj9/pull/11552

2. https://github.com/eclipse-openj9/openj9/pull/11553

3. https://github.com/eclipse-openj9/openj9/pull/11554

Building Multipart payloads for JAX-RS client and services in Open Liberty 21.0.0.5-beta

Fri, 16 Apr 2021 00:00:00 +0000

With Open Liberty 21.0.0.5-beta you can now build multipart payloads for your JAX-RS client and services. Also present in this release is Jakarta EE 9 support for oauth-2.0 and samlWeb-2.0.

We have two beta packages for Open Liberty:

All Beta Features: a larger package that contains all Open Liberty beta features (including Jakarta EE 9 beta features) and GA features and functions.
Jakarta EE 9 Beta Features: a lightweight package that contains only the Jakarta EE 9 features.

This means that you can now try out our in-development Open Liberty features by just adding the relevant coordinates to your build tools.

If you try either package, let us know what you think.

All Beta Features package

The All Beta Features package includes

Build multipart payloads for your JAX-RS client and services.
Jakarta EE 9 support for oauth-2.0 and samlWeb-2.0s

Build multipart payloads for your JAX-RS client and services

List<IAttachment> attachments = new ArrayList<>();

attachments.add(AttachmentBuilder.newBuilder("blogPost")
                                 .inputStream(new FileInputStream("/path/to/yesterdaysBlogPost.xml"))
                                 .fileName("myRenamedBlogPost.asciidoc")
                                 .contentType("text/asciidoc")
                                 .contentId("myBlogPostID")
                                 .header("X-PriorityLevel", "Medium")
                                 .build());

attachments.add(AttachmentBuilder.newBuilder("file1")
                                 .inputStream("some.xml", new FileInputStream("/path/to/myPicture.png"))
                                 .contentType("image/png")
                                 .build());

attachments.add(AttachmentBuilder.newBuilder("authorName")
                                 .inputStream(new ByteArrayInputStream("John Doe".getBytes()))
                                 .build());

Response response = client.target(BLOG_SITE_URI)
                          .request()
                          .post(Entity.entity(attachments, MediaType.MULTIPART_FORM_DATA));

For more information vist:

multipart/form-data RFC 7578

Jakarta EE 9 support for oauth-2.0 and samlWeb-2.0

The oauth-2.0 and samlWeb-2.0 features have been updated to support Jakarta EE 9. Now these features will automatically adapt to the level of Java EE or Jakarta EE that is already in use. This means that there is no change needed when using them with Jakarta EE 9.

Try it now

To try out these features, just update your build tools to pull the Open Liberty All Beta Features package instead of the main release. The beta works with Java SE 15, Java SE 11, or Java SE 8.

If you’re using Maven:

Add the following dependency to your pom.xml file:

<dependency>
  <groupId>io.openliberty.beta</groupId>
  <artifactId>openliberty-runtime</artifactId>
  <version>21.0.0.5-beta</version>
  <type>pom</type>
</dependency>

Add a dependency for the beta version of each of the APIs that you’d like to try. For example, to try MicroProfile Config 2.0:

<dependency>
  <groupId>org.eclipse.microprofile.config</groupId>
  <artifactId>microprofile-config-api</artifactId>
  <version>2.0</version>
  <scope>provided</scope>
</dependency>

Add add the following runtimeArtifact section to the configuration section of your pom.xml file:

<runtimeArtifact>
  <groupId>io.openliberty.beta</groupId>
  <artifactId>openliberty-runtime</artifactId>
  <version>21.0.0.5-beta</version>
  <type>zip</type>
</runtimeArtifact>

Or for Gradle:

dependencies {
    libertyRuntime group: 'io.openliberty.beta', name: 'openliberty-runtime', version: '[21.0.0.5-beta,)'
}

Or take a look at our Downloads page.

Jakarta EE 9 Beta Features package

This Open Liberty beta release comes complete with all of the previously released Jakarta EE9 API candidates. For more information about Open Liberty’s Jakarta EE 9 compatability, view our Open Liberty beta is Jakarta EE 9 compatible blog release.

  <featureManager>
    <feature>jakartaee-9.0</feature>
  </featureManager>

Or you can add the Web Profile convenience feature to enable all of the Jakarta EE 9 Web Profile beta features at once:

  <featureManager>
    <feature>webProfile-9.0</feature>
  </featureManager>

Try it now

If you’re using Maven, here are the coordinates:

<dependency>
    <groupId>io.openliberty.beta</groupId>
    <artifactId>openliberty-jakartaee9</artifactId>
    <version>21.0.0.5-beta</version>
    <type>zip</type>
</dependency>

Or for Gradle:

dependencies {
    libertyRuntime group: 'io.openliberty.beta', name: 'openliberty-jakartaee9', version: '[21.0.0.5-beta,)'
}

Or take a look at our Downloads page.

Your feedback is welcomed

Let us know what you think on our mailing list. If you hit a problem, post a question on StackOverflow. If you hit a bug, please raise an issue.

LDAP connection support for Kerberos authentication in Open Liberty 21.0.0.4-beta

Mon, 22 Mar 2021 00:00:00 +0000

Open Liberty 21.0.0.4-beta contains new authentication methods for LDAP connections and the complete suite of Jakarta EE 9 API candidates.

With the release of Open Liberty 21.0.0.3, MicroProfile 4.0 and associated components are promoted to the general availability release. For more information, see the Open Liberty 21.0.0.3 release blog post.

We have two beta packages for Open Liberty:

All Beta Features: a larger package that contains all Open Liberty beta features (including Jakarta EE 9 beta features) and GA features and functions.
Jakarta EE 9 Beta Features: a lightweight package that contains only the Jakarta EE 9 features.

This means that you can now try out our in-development Open Liberty features by just adding the relevant coordinates to your build tools.

If you try either package, let us know what you think.

All Beta Features package

The All Beta Features package includes the following beta features:

LDAP connection support for Kerberos authentication

LDAP connection support for Kerberos authentication

LDAP bind operations are used to authenticate clients (and the users or applications behind them) to the directory server. This establishes an authorization identity that is used for subsequent operations that are processed on that connection, and specifies the LDAP protocol version that the client uses. Before this update, the LdapRegistry element supported binding either anonymously or by using simple authentication with a user (bindDN) and password (bindPassword). This update adds an option to bind to LDAP: GSSAPI/Kerberos. Kerberos is an authentication mechanism that allows a client and service to mutually authenticate by a Key Distribution Center (KDC). In Open Liberty 21.0.0.4-beta, you can use either a Kerberos credential cache (ccache) or a Kerberos keytab file.

To update an LdapRegistry to use the GSSAPI/Kerberos option, you can set the bind authentication mechanism type using the new LdapRegistry attribute, bindAuthMechanism:

bindAuthMechanism="GSSAPI"

You also need the Kerberos principal or Service Principal Name:

krb5Principal="user1@EXAMPLE.COM"

krb5TicketCache="${server.config.dir}/security/krb5-user1.cc"

If you are using a custom Kerberos configuration file (krb.conf or krb.ini), set the file name using the global Kerberos configuration element:

<kerberos configFile="${server.config.dir}/security/krb5.conf"/>

If you are using a Kerberos keytab file to store encrypted keys for principals, set the file using the global Kerberos configuration element:

<kerberos keytab="${server.config.dir}/security/krb5.keytab" configFile="${server.config.dir}/security/krb5.conf"/>

If the Kerberos configuration file is not defined, Open Liberty will attempt to resolve by using the JDK default locations and the operating system default locations.

For the Kerberos credentials, the locations are checked in the following order: the ticket cache (if provided), the configured keytab file, and finally the JDK default location.

The following example shows how to configure the LdapRegistry element using a ticket cache and custom Kerberos config file:

<kerberos keytab= configFile="${server.config.dir}/security/krb5.conf"/>

<ldapRegistry id="LDAP" realm="SampleLdapADRealm" host="ldap_hostname" port="389" ignoreCase="true" baseDN="DC=example,DC=com" bindAuthMechanism="GSSAPI" krb5Principal="user1@EXAMPLE.COM" krb5TicketCache="${server.config.dir}/security/krb5-user1.cc" ldapType="Custom" />

The following example shows how to configure an LDAP Registry using a keytab and custom Kerberos config file:

<kerberos keytab="${server.config.dir}/security/krb5.keytab" configFile="${server.config.dir}/security/krb5.conf" />

<ldapRegistry id="LDAP" realm="SampleLdapADRealm" host="ldap_hostname" port="389" ignoreCase="true" baseDN="DC=example,DC=com" bindAuthMechanism="GSSAPI" krb5Principal="user1@EXAMPLE.COM" ldapType="Custom" />

For more information on LdapRegistry, see the LDAP User Registry documentation.

To enable this new beta function in your app, pull the All Beta Features package and add the LDAP User Registry 3.0 feature to your server.xml file:

<featureManager>
  <feature>ldapRegistry-3.0</feature>
</featureManager>

Try it now

To try out these features, just update your build tools to pull the Open Liberty All Beta Features package instead of the main release. The beta works with Java SE 15, Java SE 11, or Java SE 8.

If you’re using Maven:

Add the following dependency to your pom.xml file:

<dependency>
  <groupId>io.openliberty.beta</groupId>
  <artifactId>openliberty-runtime</artifactId>
  <version>21.0.0.4-beta</version>
  <type>pom</type>
</dependency>

Add a dependency for the beta version of each of the APIs that you’d like to try. For example, to try MicroProfile Config 2.0:

<dependency>
  <groupId>org.eclipse.microprofile.config</groupId>
  <artifactId>microprofile-config-api</artifactId>
  <version>2.0</version>
  <scope>provided</scope>
</dependency>

Add add the following runtimeArtifact section to the configuration section of your pom.xml file:

<runtimeArtifact>
  <groupId>io.openliberty.beta</groupId>
  <artifactId>openliberty-runtime</artifactId>
  <version>21.0.0.4-beta</version>
  <type>zip</type>
</runtimeArtifact>

Or for Gradle:

dependencies {
    libertyRuntime group: 'io.openliberty.beta', name: 'openliberty-runtime', version: '[21.0.0.4-beta,)'
}

Or take a look at our Downloads page.

Jakarta EE 9 Beta Features package

This Open Liberty beta release comes complete with all of the previously released Jakarta EE9 API candidates:

Jakarta Messaging 3.0 (messaging-3.0, messagingClient-3.0, messagingServer-3.0, messagingSecurity-3.0)
Jakarta Security 2.0 (appSecurity-4.0, appSecurityClient-1.0)
Jakarta XML Web Services 3.0 (xmlWS-3.0)
Jakarta Batch 2.0 (batch-2.0)
Jakarta Mail (mail-2.0)
Jakarta WebSocket 2.0 (websocket-2.0; now with full CDI integration)
RESTful Web Services 3.0 (restfulWS-3.0 and restfulWSClient-3.0)
Jakarta Server Faces 3.0 (faces-3.0)
Jakarta Connectors 2.0 (connectors-2.0)
Jakarta Enterprise Beans 4.0 (enterpriseBeans-4.0)
Jakarta Enterprise Beans Remote 4.0 (enterpriseBeansRemote-4.0)
Jakarta Enterprise Beans Home 4.0 (enterpriseBeansHome-4.0)
Jakarta Enterprise Beans Lite 4.0 (enterpriseBeansLite-4.0)
Jakarta Enterprise Beans Persistent Timers 4.0 (enterpriseBeansPersistentTimer-4.0)
Jakarta EE Application Client 9.0 (jakartaeeClient-9.0)
Jakarta Authentication 2.0 (appAuthentication-2.0)
Jakarta Authorization 2.0 (appAuthorization-2.0)
Jakarta Persistence 3.0 (includes Eclipselink 3.0-GA.) (persistence-3.0)
Jakarta XML Binding 3.0 (xmlBinding-3.0)
Jakarta Managed Beans 2.0 (managedBeans-2.0)
Jakarta Concurrency 2.0 (concurrent-2.0)
Jakarta Bean Validation 3.0 (beanValidation-3.0)
Jakarta Contexts and Dependency Injection 3.0 (cdi-3.0)
Message-Driven Beans 4.0 (mdb-4.0)
JDBC 4.2 & 4.3 (jdbc-4.2 & jdbc-4.3)
Jakarta JSON Binding 2.0 (jsonb-2.0)
Jakarta JSON Processing 2.0 (jsonp-2.0)
Jakarta Servlet 5.0 (servlet-5.0)
Jakarta Server Pages 3.0 (pages-3.0)
Jakarta Expression Language 4.0 (expressionLanguage-4.0)

For more information about Open Liberty’s Jakarta EE 9 compatability, view our Open Liberty beta is Jakarta EE 9 compatible blog release.

  <featureManager>
    <feature>jakartaee-9.0</feature>
  </featureManager>

Or you can add the Web Profile convenience feature to enable all of the Jakarta EE 9 Web Profile beta features at once:

  <featureManager>
    <feature>webProfile-9.0</feature>
  </featureManager>

Try it now

If you’re using Maven, here are the coordinates:

<dependency>
    <groupId>io.openliberty.beta</groupId>
    <artifactId>openliberty-jakartaee9</artifactId>
    <version>21.0.0.4-beta</version>
    <type>zip</type>
</dependency>

Or for Gradle:

dependencies {
    libertyRuntime group: 'io.openliberty.beta', name: 'openliberty-jakartaee9', version: '[21.0.0.4-beta,)'
}

Or take a look at our Downloads page.

We welcome your feedback

Let us know what you think on our mailing list. If you hit a problem, post a question on StackOverflow. If you hit a bug, please raise an issue.

Enabling Jakarta EE 9 for development and test by using the Eclipse Transformer

Wed, 17 Mar 2021 00:00:00 +0000

Overview

In this post, we describe how to use the Eclipse Transformer to update your applications and test artifacts for Jakarta EE 9. We also describe the steps to update Open Liberty server configurations to run Jakarta EE 9 applications.

The core problem that is introduced by Jakarta EE 9 is the renaming of package prefixes from javax to jakarta for APIs and properties. As a consequence, existing applications that run against Java EE 7 or Jakarta EE 8 do not run against Jakarta EE 9. To run existing applications as Jakarta EE 9 applications, specific package references must be updated.

To solve this problem, the Open Liberty development team created the Eclipse Transformer. This open source project provides a utility that updates package references in various artifacts.

The development team uses the Eclipse Transformer to update bundle implementation archives. The team also uses the transformer to update test artifacts, including applications, test classes, and Open Liberty server configurations.

Similarly, you can use the Eclipse Transformer to update applications, test classes, and server configurations. Updates to applications and test classes are usually necessary. Updates to server configurations are necessary when using Open Liberty.

The transformer is quick and efficient. When integrated as a build step, as is done in Open Liberty builds, using the transformer avoids the creation of new Jakarta EE 9 source files.

Although this post focuses on updating from Jakarta EE 8 to Jakarta EE 9, the same information holds true for updating from Java EE 7 to Jakarta EE 9.

Test transformation strategy

To transform test artifacts, package references must be updated to change old javax package references into new jakarta package references. Package references can be in several locations, including test applications, test code, and server configurations.

Additionally, in Open Liberty, server configurations must be updated to replace old Jakarta EE 8 features with corresponding new Jakarta EE 9 features. Currently, the transformer does not have the rules data necessary to specify feature name updates. These updates must either be made manually, through custom code, or by creating new rules data for the transformer. For more information about updating Open Liberty features, see Updating Open Liberty features in server configurations.

Preparing to run the transformer

A transformer image can be obtained either by downloading the image or by building an image by using the open source repository.

Top-level downloads links are available within the project pages.
Several current snapshots are usually available.

Alternatively, the transformer can be built by cloning the Eclipse Transformer repository and invoking maven to build the transformer JAR file:

    mvn clean package

The maven build creates the distribution JAR file at:

    org.eclipse.transformer.cli/target/org.eclipse.transformer.cli-0.3.0-SNAPSHOT-distribution.jar

Unzipping the downloaded or built distribution obtains the transformer and prerequisite JAR files:

    unzip org.eclipse.transformer.cli-0.3.0-SNAPSHOT-distribution.jar

    org.eclipse.transformer.cli-0.3.0-SNAPSHOT.jar
    libs/org.eclipse.transformer-0.3.0-SNAPSHOT.jar
    libs/biz.aQute.bnd.transform-5.2.0.jar
    libs/slf4j-api-1.7.25.jar
    libs/commons-cli-1.4.jar
    libs/slf4j-simple-1.7.30.jar

Running the transformer

The Eclipse Transformer can be run directly from the command line, as a Gradle task, or from Java code. This post describes using the transformer from the command line. For more information, see the transformer project pages.

To run the transformer by using the default rules, run the following command:

  java -jar org.eclipse.transformer.cli-0.3.0-SNAPSHOT.jar \
    <target_location> \
    <output_location>

The target location can be a packed application archive file (EAR, WAR, RAR, or JAR) or a directory that contains the fully or partially expanded contents of one of these archives. The target can also be a directory that contains Java source, or a directory that contains several application archives. It can even be a single file, such as a server.xml file. The transformer processes all of the artifacts in the target location. Transformed artifacts are written to the output location.

The org.eclipse.transformer.cli-0.3.0-SNAPSHOT.jar file is a runnable JAR file that specifies org.eclipse.transformer.jakarta.JakartaTransformer as the main class and uses the necessary JAR files from the libs folder in its class path.

You can run the transformer using custom rules by specifying options on the command line. The additional options specify local rules files that the transformer uses instead of the default rules files.

For example, to use Open Liberty rules data, which can be more up to date than the default rules data, download Open Liberty Rules. Then, pull in the downloaded rules data by adding options -tr, -td, and -tf, to the command-line invocation:

  java -jar org.eclipse.transformer.cli-0.3.0-SNAPSHOT.jar \
    <target_location> \
    <output_location> \
    -tr ${rules}/jakarta-renames.properties \
    -td ${rules}/jakarta-direct.properties \
    -tf ${rules}/jakarta-xml-master.properties

The -tr option specifies a properties file that contains package rename data. The -td option specifies a properties file that contains java direct string replacement data. The -tf option specifies a main properties file that links to other properties files. Each of the linked properties files contains replacement data for text-like files that match specific patterns, as specified in the main properties file.

These three command-line options are most important for application and test developers. Other command line options are available, but are less important. For example, the option -tb is used to specify data for transforming bundle archives, while the option -ts is used to specify which target files are to be transformed. For more information about command-line options, run the transformer with either the -usage option or with the -help option.

  java -jar org.eclipse.transformer.cli-0.3.0-SNAPSHOT.jar \
    -usage

Transforming server configurations

When you specify your server.xml file as a target location for the transformer, Open Liberty server configuration elements that contain javax package references are updated to jakarta. For example, the destinationType attribute of the jmsActivationSpec element contains a javax package reference:

  <jmsActivationSpec id="SharedSubscriptionWithMsgSel/TestTopic1">
    <properties.wasJms
        destinationRef="jms/FAT_TOPIC"
        destinationType="javax.jms.Topic"
        subscriptionDurability="DurableShared"
        clientId="cid1"
        subscriptionName="DURSUB"/>
  </jmsActivationSpec>

This configuration is updated to:

  <jmsActivationSpec id="SharedSubscriptionWithMsgSel/TestTopic1">
    <properties.wasJms
        destinationRef="jms/FAT_TOPIC"
        destinationType="jakarta.jms.Topic"
        subscriptionDurability="DurableShared"
        clientId="cid1"
        subscriptionName="DURSUB"/>
  </jmsActivationSpec>

Only package names in the server configuration are updated by the transformer. Features must be handled separately

Updating Open Liberty features in server configurations

For Jakarta EE 9 applications to run in Open Liberty, new Jakarta EE 9 features must be specified in the server configuration. In many cases, the new Jakarta EE 9 features use the same short names as the corresponding Jakarta EE 8 features. In those cases, the Jakarta EE 9 features simply have an updated feature version. For example, cdi-2.0 was updated to cdi-3.0. However, in some cases, the feature short name is also different, as with ejb-3.2, which was updated to enterpriseBeans-4.0.

If an old short name is incorrectly used with a new Jakarta EE 9 version, the server does not start, and the server logs provide information to say which new feature short name must be used. For example, if ejb-3.2 is incorrectly changed to ejb-4.0, the server logs indicate that enterpriseBeans-4.0 must be used.

Currently, the transformer cannot update Open Liberty features because it is missing rules data to specify the updates. Features must be updated manually or by custom code.

The following table lists features for which only the feature version is updated:

Table 1. Jakarta EE 8 to Jakarta EE 9 feature updates: version only
Jakarta EE 8 feature name	Jakarta EE 9 feature name
appClientSupport-1.0	appClientSupport-2.0
appSecurity-3.0	appSecurity-4.0
batch-1.0	batch-2.0
beanValidation-2.0	beanValidation-3.0
cdi-2.0	cdi-3.0
concurrent-1.0	concurrent-2.0
jakartaee-8.0	jakartaee-9.0
jsonb-1.0	jsonb-2.0
jsonbContainer-1.0	jsonbContainer-2.0
jsonp-1.1	jsonp-2.0
jsonpContainer-1.1	jsonpContainer-2.0
managedBeans-1.0	managedBeans-2.0
mdb-3.2	mdb-4.0
servlet-4.0	servlet-5.0
webProfile-8.0	webProfile-9.0
websocket-1.1	websocket-2.0

The following table lists features for which both the feature short name and the feature version are updated:

Table 2. Jakarta EE 8 to Jakarta EE 9 feature updates: short name and version
Jakarta EE 8 feature name	Jakarta EE 9 feature name
ejb-3.2	enterpriseBeans-4.0
ejbHome-3.2	enterpriseBeansHome-4.0
ejbLite-3.2	enterpriseBeansLite-4.0
ejbPersistentTimer-3.2	enterpriseBeansPersistentTimer-4.0
ejbRemote-3.2	enterpriseBeansRemote-4.0
el-3.0	expressionLanguage-4.0
jacc-1.5	appAuthorization-2.0
jaspic-1.1	appAuthentication-2.0
javaee-8.0	jakartaee-9.0
javaeeClient-8.0	jakartaeeClient-9.0
javaMail-1.6	mail-2.0
jaxb-2.2	xmlBinding-3.0
jaxrs-2.1	restfulWS-3.0
jaxrsClient-2.1	restfulWSClient-3.0
jaxws-2.2	xmlWS-3.0
jca-1.7	connectors-2.0
jcaInboundSecurity-1.0	connectorsInboundSecurity-2.0
jms-2.0	messaging-3.0
jpa-2.2	persistence-3.0
jpaContainer-2.2	persistenceContainer-3.0
jsf-2.3	faces-3.0
jsfContainer-2.3	facesContainer-3.0
jsp-2.3	pages-3.0
wasJmsClient-2.0	messagingClient-3.0
wasJmsSecurity-1.0	messagingSecurity-3.0
wasJmsServer-1.0	messagingServer-3.0

Reference Resources

Eclipse Transformer Project Links

The Main Eclipse Transformer page.
The Eclipse Transformer GIT repository.
Top level downloads page.
Several current transformer snapshots.

Open Liberty Project Links

Open Liberty transformer data: dev/wlp-jakartaee-transform/rules.
Open Liberty gradle tasks used to transform bundle implementation JAR files: dev/wlp-gradle/subprojects/tasks.gradle.
Open Liberty Java transformer invocation used on FAT (Feature Acceptance Test) artifacts: JakartaEE9Action.transformApp.
Java source for the the custom Open Liberty "repeat test action": dev/fattest.simplicity/src/componenttest/rules/repeater/JakartaEE9Action.java.

Open Liberty beta is Jakarta EE 9 compatible

Fri, 05 Mar 2021 00:00:00 +0000

Late last year, the Jakarta EE community released the next step in the evolution of the Jakarta EE specification. Version 9.0 of the Jakarta EE specification focuses on renaming packages and namespaces by changing to jakarta prefixed packages names in the API and to the jakarta.ee namespace in the deployment descriptor files. Additionally, the specification makes optional or removes older functions that have been deprecated or stabilized for many years.

Over the last year, the Open Liberty development team worked to implement the Jakarta EE 9 specification as it was being finalized. To avoid having to duplicate the code just to change the API package names, the team developed an open source byte code transformation technology. With this technology, Jakarta EE 8 compatible code is transformed to work with Jakarta EE 9 APIs by manipulating the byte code to convert class and property reference prefixes from javax to jakarta.

As of the 21.0.0.2-beta release, Open Liberty is the first vendor product to be Jakarta EE Web Profile 9.0 compatible. With the recent 21.0.0.3-beta release, Open Liberty is the first vendor product to be added to the Jakarta EE Platform 9.0 compatibility list. These releases continue to demonstrate Open Liberty’s leadership in the Jakarta EE technologies. With the upcoming Jakarta EE 9.1 release that adds Java 11 support to the TCK, I anticipate that Open Liberty will be added to the compatibility list for the 9.1 release when it is available since Open Liberty has supported Java 11 for the last 2 years.

Even with reaching these milestones, the journey to support Jakarta EE 9 in the Open Liberty product will continue until it is available in a non-beta release. Many Liberty value-add features need to be enabled to run with Jakarta EE 9 and still continue to work with the previous EE specifications. In the coming months, you will see additional enablement of these features in the beta releases until all are ready. Thanks to the Open Liberty pluggable feature architecture, you will be able to run your Java EE 7, Java / Jakarta EE 8 and Jakarta EE 9 applications with the same product install.

MicroProfile Context Propagation 1.2, RequestTiming 1.0 and JakartaMail 2.0 in Open Liberty 21.0.0.3-beta

Fri, 19 Feb 2021 00:00:00 +0000

Open Liberty 21.0.0.3-beta contains five new features; MicroProfile Context Propagation 1.2, JakartaMail 2.0, the ability to control hung request thread dumps, automatic cleanup of leaked connections, and finally, a new expandLocation property for App Manager configuration.

We have two beta packages for Open Liberty:

All Beta Features: a larger package that contains all Open Liberty beta features (including Jakarta EE 9 beta features) and GA features and functions.
Jakarta EE 9 Beta Features: a lightweight package that contains only the Jakarta EE 9 features.

Try it now

This means that you can now try out our in-development Open Liberty features by just adding the relevant coordinates to your build tools.

If you try either package, let us know what you think.

In addition to all Jakarta EE 9 and MicroProfile 4.0 beta features, Open Liberty 21.0.0.3-beta also contains five brand new features.

All Beta Features package

The All Beta Features package includes the following beta features:

MicroProfile Context Propagation 1.2
Ability to control whether thread dumps are collected when a hung request is detected in the Request Timing feature
Automatic Cleanup of Leaked Connections
expandLocation property for App Manager configuration

These features also join all the MicroProfile 4.0 features:

MicroProfile Context Propagation 1.2

MicroProfile Context Propagation is a standalone MicroProfile specification. This new Open Liberty feature enables you to create completion stages that behave deterministically with respect to thread context and leverages the autonomic tuning of the Liberty global thread pool for asynchronous dependent stages.

The 1.2 release of MicroProfile Context Propagation aligns with the MicroProfile 4.0 platform, specifically addressing a difference in how MicroProfile Config 2.0 treats empty value configuration properties. When using MicroProfile Config to specify an empty list of thread context types for MicroProfile Context Propagation to use as defaults, use a value of None rather than an empty value. An empty value in MicroProfile Config 2.0 indicates to override any lower ordinal config sources and instead use the built-in default value for the property. For example, the combination of mp.context.ManagedExecutor.cleared=None and mp.context.ManagedExecutor.propagated=Remaining causes every context type to be propagated.

To enable the MicroProfile Context Propagation 1.2 feature, add the following to your server configuration,

<featureManager>
  <feature>mpContextPropagation-1.2</feature>
  <!-- other features used by example code... -->
  <feature>servlet-4.0</feature>
  <feature>jdbc-4.2</feature>
  <feature>jndi-1.0</feature>
</featureManager>

Example usage within a Servlet:

private ManagedExecutor executor;

public void init(ServletConfig config) throws ServletException {
    executor = ManagedExecutor.builder()
                .propagated(ThreadContext.APPLICATION)
                .cleared(ThreadContext.ALL_REMAINING)
                .build();
}

public void destroy() {
    executor.shutdownNow();
}

public void doGet(HttpServletRequest req, HttpServletResponse resp)
    throws ServletException, IOException {
    ...
    executor.copy(unmanagedCompletionStage).thenAcceptAsync(value -> {
        // requires java:comp namespace of the application,
        DataSource ds = InitialContext.doLookup("java:comp/env/jdbc/ds");
        ...
    });
}

Find out more:

Ability to control whether thread dumps are collected when a hung request is detected in the Request Timing feature

The Request Timing feature (requestTiming-1.0) provides diagnostic information when the duration of any request exceeds the configured threshold. It provides a way to monitor requests with respect to time. The feature can automatically detect slow and hung requests and provide detailed diagnostic information; warning messages, thread stacks, and the creation of thread dumps.

When a hung request is detected in the Request Timing feature, a warning message is written in the messages log file along with a dump of the events that happened during the request. Following that, a set of three thread dumps will be initiated, 1 minute apart. After the completion of the three thread dumps, further set of three thread dumps are created only if new requests are detected to be hanging.

Some operations teams do not want so many thread dumps to be generated due to performance overhead on requests that are known to be long. In previous Open Liberty releases, there was no option to disable the thread dumps from being generated.

You can now control whether the Request Timing feature collects thread dumps. By setting the NEW enableThreadDumps Request Timing server configuration attribute to false, thread dumps will not be created during hung requests. If the new server configuration attribute is set to true or not specified at all, thread dumps will still be created.

The new Request Timing server configuration attribute can be configured in your server.xml as follows:

<requestTiming includeContextInfo="true" slowRequestThreshold="120s" hungRequestThreshold="10s" sampleRate="1" enableThreadDumps="false"></requestTiming>`

The enableThreadDumps server configuration attribute can also be used in embedded Request Timing sub-elements: <servletTiming/> or <jdbcTiming/>, as follows:

<requestTiming includeContextInfo="true" slowRequestThreshold="120s" hungRequestThreshold="10s" sampleRate="1">
    <servletTiming appName="MyApp" servletName="MyServletApp" slowRequestThreshold="100s" hungRequestThreshold="5s" enableThreadDumps="false"/>
</requestTiming>`

Note: An embedded <servletTiming/> or <jdbcTiming/> configuration element in the server.xml file overrides the configured slow and hung request threshold that are defined in <requestTiming/>.

For more information on the Request Timing feature, please refer to the following documentations: - Open Liberty Documentation on requestTiming-1.0 feature - Open Liberty Documentation on requestTiming Configuration

Automatic Cleanup of Leaked Connections

Open Liberty connection management is enhanced with the ability to automatically detect and close unsharable connections that are left open by the application across the end of a request.

Occasionally, application code might forget to close an unsharable connection that it obtains. This prevents the connection from being returned to the connection pool for use by other requests. Over time, these leaked connections can degrade performance and eventually exhaust the connection pool. Open Liberty connection management now has the ability to detect and automatically close these leaked connections to prevent this from happening.

To take advantage of this new capability, configure one of the Open Liberty features that leverages the connectionManager element. For example, JDBC:

<featureManager>
  <feature>jdbc-4.2</feature>
  <feature>jndi-1.0</feature>
  <!-- more features -->
</featureManager>

Configure connection managers for your data sources to enable the new autoCloseConnections attribute,

<dataSource id="DefaultDataSource">
  <connectionManager maxPoolSize="10" autoCloseConnections="true"/>
    <jdbcDriver libraryRef="PostgreSQL"/>
    <properties.postgresql databaseName="TESTDB" serverName="localhost" portNumber="5432"/>
</dataSource>

<library id="PostgreSQL">
    <file name="/usr/local/postgresql/postgresql-42.2.18.jar"/>
</library>

Find out more:

connectionManager config documentation

expandLocation property for App Manager configuration

This enhancement allows the user to specify a expansion location (expandLocation) on the applicationManager configuration to be utilized when the autoExpand attribute is set to "true". As currently implemented, when an application is autoExpanded the default location for the expanded files are hard coded to ${server.config.dir}/apps/expanded/.

The user is now able to configure that location to a new value on the file system.

For example:

<applicationManager autoExpand="true" expandLocation="${server.config.dir}/myApps/" />

would result in the application being expanded at ${server.config.dir}/myApps/{appname}/

This enhancement gives users more flexibility regarding the location of their expanded applications.

You can find out more at Open Liberty applicationManager documentation

Jakarta EE 9 Beta Features package

This Open Liberty beta introduces the following Jakarta EE 9 feature which now possesses its all-new Jakarta EE 9 package name:

JakartaMail (mail-2.0)

This feature joins the Jakarta EE 9 features in Open Liberty 21.0.0.2-beta Jakarta functions.

JakartaMail

The Java EE framework has been migrated to the open source Eclipse Jakarta EE Project. As part of this migration JavaMail version 1.6 has been migrated to JakartaMail 2.0. The API package names for the classes previously found under the javax.mail have been migrated to jakarta.mail.

The Jakarta mail API as described by the Jakarta Mail FAQ “The Jakarta Mail API is a set of abstract APIs that model a mail system. (Jakarta Mail was previously known as JavaMail.) The API provides a platform independent and protocol independent framework to build Java technology based email client applications. The Jakarta Mail API provides facilities for reading and sending email. Service providers implement particular protocols. Several service providers are included with the Jakarta Mail API package; others are available separately. The Jakarta Mail API is implemented as a Java optional package that can be used on JDK 1.4 and later on any operating system. The Jakarta Mail API is also a required part of the Jakarta EE Platform and the Java Platform, Enterprise Edition (Java EE).”

Configuring mail sessions works basically the same as with the Liberty Feature JavaMail-1.5 and JavaMail-1.6. They can be configured using the API, or through the server.xml

Below is an example of a SMTP Mail session configured through the server.xml:

<featureManager>
  <feature>mail-2.0</feature>
  <feature>jndi-1.0</feature>
</featureManager>

<mailSession>
      <mailSessionID>testSMTPMailSession</mailSessionID>
      <jndiName>TestingApp/SMTPMailSessionServlet/testSMTPMailSession</jndiName>
      <description>mailSession for testing SMTP protocol</description>
      <transportProtocol>smtp</transportProtocol>
      <host>localhost</host>
      <user>somuser@someemailserver.com</user>
      <password>usersPassword</password>
      <from>someuser@someemailserver.com</from>
      <property name="mail.smtp.host" value="localhost" \>
      <property name="mail.smtp.port" value="3025" \>
  </mailSession>

Find out more:

Enable the Jakarta EE 9 beta features in your server’s server.xml configuration file. You can enable the individual features you want or you can just add the Jakarta EE 9 convenience feature to enable all of the Jakarta EE 9 beta features at once:

  <featureManager>
    <feature>jakartaee-9.0</feature>
  </featureManager>

Or you can add the Web Profile convenience feature to enable all of the Jakarta EE 9 Web Profile beta features at once:

  <featureManager>
    <feature>webProfile-9.0</feature>
  </featureManager>

Try it now

To try out these features, just update your build tools to pull the Open Liberty All Beta or Jakarta EE 9 Features package instead of the main release. The beta works with Java SE 15, Java SE 11, or Java SE 8.

If you’re using Maven, here are the coordinates for All Beta:

<dependency>
  <groupId>io.openliberty.beta</groupId>
  <artifactId>openliberty-runtime</artifactId>
  <version>21.0.0.3-beta</version>
  <type>pom</type>
</dependency>

Or for Jakarta EE 9:

<dependency>
    <groupId>io.openliberty.beta</groupId>
    <artifactId>openliberty-jakartaee9</artifactId>
    <version>21.0.0.3-beta</version>
    <type>zip</type>
</dependency>

Gradle for All Beta:

dependencies {
    libertyRuntime group: 'io.openliberty.beta', name: 'openliberty-runtime', version: '[21.0.0.3-beta,)'
}

Or for Jakarta EE 9:

dependencies {
    libertyRuntime group: 'io.openliberty.beta', name: 'openliberty-jakartaee9', version: '[21.0.0.3-beta,)'
}

Or take a look at our Downloads page.

Your feedback is welcomed

Let us know what you think on our mailing list. If you hit a problem, post a question on StackOverflow. If you hit a bug, please raise an issue.

With Jakarta Batch and XML Web Services features, all Jakarta EE 9 features now available in Open Liberty 21.0.0.2-beta

Tue, 26 Jan 2021 00:00:00 +0000

New in Open Liberty 21.0.0.2-beta are four Jakarta EE 9 packages, Jakarta Messaging 3.0, Jakarta Security 2.0, Jakarta Batch 2.0, and Jakarta XML Web Services 3.0, that join the collection of Jakarta EE 9 packages already available within Open Liberty. With these additions, all features needed to run Jakarta EE 9 applications are available in this Open Liberty beta release. Open Liberty 21.0.0.2-beta also includes previews for 7 of the updated MicroProfile features, including Config, Metrics, OpenTracing, Health, OpenAPI, Rest Client, and JWT.

We have two beta packages for Open Liberty:

Jakarta EE 9 Beta Features: a lightweight package that contains only the Jakarta EE 9 features.
All Beta Features: a larger package that contains all Open Liberty beta features (including Jakarta EE 9 beta features) and GA features and functions.

This means that you can now try out our in-development Open Liberty features by just adding the relevant coordinates to your build tools.

If you try either package, let us know what you think.

Jakarta EE 9 Beta Features package

The main change visible to developers in Jakarta EE is the names of packages changing to accomodate the new jakarta.* namespace. In this Open Liberty beta, we have a number of new API Release Candidates to join the expanding library of supported Jakarta packages.

This Open Liberty beta introduces the following Jakarta EE 9 features which now possess their all-new Jakarta EE 9 package names:

Jakarta Messaging 3.0 (messaging-3.0, messagingClient-3.0, messagingServer-3.0, messagingSecurity-3.0)
Jakarta Security 2.0 (appSecurity-4.0, appSecurityClient-1.0)
Jakarta XML Web Services 3.0 (xmlWS-3.0)
Jakarta Batch 2.0 (batch-2.0)

These join the Jakarta EE 9 features in previous Open Liberty betas:

Jakarta Mail (mail-2.0)
Jakarta Faces Container 3.0 (facesContainer-3.0)
Jakarta Enterprise Beans Persistent Timer 4.0 (enterpriseBeansPersistentTimer-4.0)
Jakarta Password Utilities 1.0 (passwordUtilities-1.0)
Jakarta Connectors 2.0 Inbound Security (connectorsInboundSecurity-2.0)
Jakarta WebSocket 2.0 (websocket-2.0; now with full CDI integration)
RESTful Web Services 3.0 (restfulWS-3.0 and restfulWSClient-3.0)
Jakarta Server Faces 3.0 (faces-3.0)
Jakarta Connectors 2.0 (connectors-2.0)
Jakarta Enterprise Beans 4.0 (enterpriseBeans-4.0)
Jakarta Enterprise Beans Remote 4.0 (enterpriseBeansRemote-4.0)
Jakarta Enterprise Beans Home 4.0 (enterpriseBeansHome-4.0)
Jakarta Enterprise Beans Lite 4.0 (enterpriseBeansLite-4.0)
Jakarta Enterprise Beans Persistent Timers 4.0 (enterpriseBeansPersistentTimer-4.0)
Jakarta EE Application Client 9.0 (jakartaeeClient-9.0)
Jakarta Authentication 2.0 (appAuthentication-2.0)
Jakarta Authorization 2.0 (appAuthorization-2.0)
Jakarta Persistence 3.0 (includes Eclipselink 3.0-GA.) (persistence-3.0)
Jakarta XML Binding 3.0 (xmlBinding-3.0)
Jakarta Managed Beans 2.0 (managedBeans-2.0)
Jakarta Concurrency 2.0 (concurrent-2.0)
Jakarta Bean Validation 3.0 (beanValidation-3.0)
Jakarta Contexts and Dependency Injection 3.0 (cdi-3.0)
Message-Driven Beans 4.0 (mdb-4.0)
JDBC 4.2 & 4.3 (jdbc-4.2 & jdbc-4.3)
Jakarta JSON Binding 2.0 (jsonb-2.0)
Jakarta JSON Processing 2.0 (jsonp-2.0)
Jakarta Servlet 5.0 (servlet-5.0)
Jakarta Server Pages 3.0 (pages-3.0)
Jakarta Expression Language 4.0 (expressionLanguage-4.0)

Jakarta Messaging 3.0

Jakarta Messaging is an API and services that enable applications to create, send, and receive messages via loosely coupled, reliable asynchronous communications. Support for version 3.0 updates the API and services to the jakarta.* namespace and introduces four new features for Jakarta EE 9: messaging-3.0, messagingClient-3.0, messagingServer-3.0, messagingSecurity-3.0.

Configuration is the same as the corresponding features for Jakarta EE 8 (jms-2.0, wasJmsClient-2.0, wasJmsServer-1.0, wasJmsSecurity-1.0) with one exception: version 3.0 support does not introduce a new feature corresponding to jmsMdb-1.0. Instead, use Jakarta EE 9 feature mdb-4.0 when deploying message-driven beans to connect to MQ providers, Jakarta Connectors resource adapters, or the embedded messaging server.

To enable the new Jakarta EE 9 messaging features, add them to your server.xml. Here’s a feature configuration that enables applications to access message queues via the Messaging 3.0 API, enables message-driven beans to connect to the embedded messaging server, and enables JNDI lookups for messaging resources.

The following features can be included in your server.xml:

 <featureManager>
       <feature>messagingClient-3.0</feature>
       <feature>mdb-4.0</feature>
       <feature>jndi-1.0</feature>
 </featureManager>

Jakarta Messaging 3.0 was originally included in the Open Liberty 21.0.0.1-beta, but missed publication.

Additional information about the Jakarta Messaging 3.0 specification can be found here.

Jakarta Security 2.0

The new appSecurity-4.0 feature has been created to support Jakarta EE 9 and introduces Jakarta Security 2.0 support. The appSecurityClient-1.0, audit-1.0, constrainedDelegation-1.0, jcaInboundSecurity-1.0, jwt-1.0, passwordUtilities-1.0 and spnego-1.0 features have been updated to also support Jakarta EE 9.

The appSecurity-4.0 feature must be added to server.xml when using application security with Jakarta EE 9. The other Liberty security features will automatically adapt to the level of Java EE or Jakarta EE that is already in use, so no change is needed when using them with Jakarta EE 9.

The following features can be included in your server.xml:

 <featureManager>
       <feature>appSecurity-4.0</feature>
       <feature>appSecurityClient-1.0</feature>
       <feature>audit-1.0</feature>
       <feature>constrainedDelegation-1.0</feature>
       <feature>jcaInboundSecurity-1.0</feature>
       <feature>jwt-1.0</feature>
       <feature>passwordUtilities-1.0</feature>
       <feature>spnego-1.0</feature>
 </featureManager>

Additional information about the Jakarta Security 2.0 specification can be found here.

Jakarta XML Web Services 3.0

Jakarta XML Web Services 3.0 is an API that enables applications to create SOAP based Web Services. The xmlWS-3.0 feature provides API updates to the Jakarta XML Web Services 3.0 API, Jakarta Web Services Metadata 3.0 API and Jakarta SOAP with Attachments 2.0 API. The jakartaeeClient-9.0 feature has been also been updated to provide Application Client Container support for the Jakarta XML Web Services 3.0 API.

The xmlWS-3.0 feature provides the Jakarta EE 9 XML Web Services 3.0 tools for Top Down and Bottom Up Web Services Creation: wsgen and wsimport. These can be found in a new location in the Open Liberty image: wlp/bin/xmlWS/. Both commands perform nearly identical to the Jakarta EE 8 tooling, with the exception that the -target argument is no longer required.

To enable the new Jakarta EE 9 XML Web Services 3.0 feature, add the xmlWS-3.0 feature to your server.xml. Here’s an example of what the feature configuration looks like:

 <featureManager>
       <feature>xmlWS-3.0</feature>
 </featureManager>

To run Jakarta XML Web Services on the Application Client Container: Here’s an example of what the client.xml configuration looks:

 <featureManager>
       <feature>jakartaeeClient-9.0</feature>
 </featureManager>

For more information see the Jakarta XML Web Services Specification.

  <featureManager>
    <feature>jakartaee-9.0</feature>
  </featureManager>

Or you can add the Web Profile convenience feature to enable all of the Jakarta EE 9 Web Profile beta features at once:

  <featureManager>
    <feature>webProfile-9.0</feature>
  </featureManager>

Try it now

If you’re using Maven, add the following runtimeArtifact section to the configuration section of your pom.xml file:

<runtimeArtifact>
    <groupId>io.openliberty.beta</groupId>
    <artifactId>openliberty-jakartaee9</artifactId>
    <version>21.0.0.2-beta</version>
    <type>zip</type>
</runtimeArtifact>

Or for Gradle:

dependencies {
    libertyRuntime group: 'io.openliberty.beta', name: 'openliberty-jakartaee9', version: '[21.0.0.2-beta,)'
}

Or take a look at our Downloads page.

All Beta Features package

The All Beta Features package includes the following beta features (in addition to all Jakarta EE 9 beta features):

Currently, due to an issue in MicroProfile Fault Tolerance 3.0, neither the mpFaultTolerance-3.0 feature nor the microProfile-4.0 convenience feature can be used in the Open Liberty 21.0.0.2-beta. All other MicroProfile 4.0 features can still be individually installed.

Try it now

To try out these features, just update your build tools to pull the Open Liberty All Beta Features package instead of the main release. The beta works with Java SE 15, Java SE 11, or Java SE 8.

If you’re using Maven, add the following runtimeArtifact section to the configuration section of your pom.xml file:

<runtimeArtifact>
    <groupId>io.openliberty.beta</groupId>
    <artifactId>openliberty-runtime</artifactId>
    <version>21.0.0.2-beta</version>
    <type>zip</type>
</runtimeArtifact>

Or for Gradle:

dependencies {
    libertyRuntime group: 'io.openliberty.beta', name: 'openliberty-runtime', version: '[21.0.0.2-beta,)'
}

Or take a look at our Downloads page.

Your feedback is welcomed

Let us know what you think on our mailing list. If you hit a problem, post a question on StackOverflow. If you hit a bug, please raise an issue.

Get a jump on Jakarta EE9 with Open Liberty Beta

Wed, 13 Jan 2021 00:00:00 +0000

MicroProfile Rest Client 2.0, using Kubernetes secrets in Liberty variables and more Jakarta EE 9 features in Open Liberty 21.0.0.1-beta

Tue, 24 Nov 2020 00:00:00 +0000

Open Liberty 21.0.0.1-beta provides MicroProfile Rest Client 2.0 (which is part of MicoProfile 4.0), which adds support for HTTP proxy servers as well as automatically following HTTP redirects. Also, you can now use Kubernetes secrets in Liberty variables, plus Jakarta Faces Container 3.0 and Jakarta Enterprise Beans Persistent Timer 4.0 which are part of Jakarta EE 9.

We have two beta packages for Open Liberty:

All Beta Features: a larger package that contains all Open Liberty beta features (including Jakarta EE 9 beta features) and GA features and functions.
Jakarta EE 9 Beta Features: a lightweight package that contains only the Jakarta EE 9 features.

This means that you can now try out our in-development Open Liberty features by just adding the relevant coordinates to your build tools.

If you try either package, let us know what you think.

All Beta Features package

The All Beta Features package includes the following beta features:

MicroProfile Rest Client 2.0
Using Kubernetes secrets in Liberty variables

MicroProfile Rest Client 2.0

MicroProfile REST Client is a type-safe client API enabling rapid development of applications capable of consuming RESTful services. Version 2.0 is the latest update and adds support for HTTP proxy servers, automatically following HTTP redirects, Server Sent Events, and additional configuration options for JSON-B providers and multiple query parameters.

To enable this feature, add <feature>mpRestClient-2.0</feature> to the list of features in the <featureManager> element as shown in the example below:

    <featureManager>
        <feature>mpRestClient-2.0</feature>
    </featureManager>

Alternatively, the microprofile-4.0 convenience feature can be used instead, as shown below:

    <featureManager>
        <feature>microprofile-4.0</feature>
    </featureManager>

In order to start coding with the updated API, you will also need to pull in the MP Rest Client 2.0 dependencies. If you use Maven, try these coordinates:

<dependency>
    <groupId>org.eclipse.microprofile.rest.client</groupId>
    <artifactId>microprofile-rest-client-api</artifactId>
    <version>2.0</version>
    <scope>provided</scope>
</dependency>

or, if you use Gradle:

dependencies {
    mpRestClient group: 'org.eclipse.microprofile.rest.client', name: 'microprofile-rest-client-api', version: '2.0'
}

This allows you to change how multi-valued query parameters are formatted, specify a proxy server, configure the client to automatically follow redirects and more. Here is an example:

MyClient client =
    RestClientBuilder.newBuilder()
                     .baseUri(someURI)
                     .queryParamStyle(QueryParamStyle.COMMA_SEPARATED) // or ARRAY_PAIRS or MULTI_PAIRS (default)...
                     .proxyAddress("myProxyServer", 1080)
                     .followRedirects(true)
                     .build(MyMultiValuedQueryParamClient.class);

These can also be configured via MP Config using the following properties, respectively:

com.mypkg.MyClient/mp-rest/queryParamStyle=COMMA_SEPARATED
com.mypkg.MyClient/mp-rest/proxyAddress=myProxyServer:1080
com.mypkg.MyClient/mp-rest/followRedirects=true

In a future blog post, we’ll discuss how you can also use MP Rest Client 2.0 to consume Server Sent Events.

For examples of how to use these new features, please refer to the specification document or the MicroProfile Rest Client project page.

You can also see these new features in action below:

Using Kubernetes secrets in Liberty variables

In a cloud environment, sensitive information such as passwords and OAuth tokens may be stored in Kubernetes secrets. To access these secrets today in Liberty via configuration variables they would need to be exposed as environment variables in a Kubernetes pod. This update will allow configuration variables to be automatically populated from Kubernetes secrets without having to expose them as environment variables.

To make use of this function, the Kubernetes secrets need to be mapped to the file system, either by using the service binding operator or by mounting the secrets to a volume in the pod definition. Files will be read from the location defined in the SERVICE_BINDING_ROOT environment variable, which defaults to WLP_CONFIG_DIR/bindings. The variable name will be taken from the name of the file, and the value will be the contents of the file.

For example, we may have a Kubernetes secret named 'account-database' that contains a username and password:

The service binding operator can automatically map that secret to the file system, or it could be done manually in a deployment definition:

The above definition will result in the files /bindings/account-database/username and /bindings/account-database/password being created when the pod is created. Liberty will create variables from both files, and users can access them using normal Liberty variable syntax, ${account-database/username} and ${account-database/password}.

For more information:

Try it now

To try out these features, just update your build tools to pull the Open Liberty All Beta Features package instead of the main release. The beta works with Java SE 15, Java SE 11, or Java SE 8.

If you’re using Maven, here are the coordinates:

<dependency>
  <groupId>io.openliberty.beta</groupId>
  <artifactId>openliberty-runtime</artifactId>
  <version>21.0.0.1-beta</version>
  <type>pom</type>
</dependency>

Or for Gradle:

dependencies {
    libertyRuntime group: 'io.openliberty.beta', name: 'openliberty-runtime', version: '[21.0.0.1-beta,)'
}

Or take a look at our Downloads page.

Jakarta EE 9 Beta Features package

The main change visible to developers in Jakarta EE is the names of packages changing to accomodate the new jakarta.* namespace. In this Open Liberty beta, we have two new API Release Candidates to join the expanding library of supported Jakarta packages.

This Open Liberty beta introduces the following Jakarta EE 9 features which now possess their all-new Jakarta EE 9 package names:

Jakarta Faces Container 3.0 (facesContainer-3.0)
Jakarta Enterprise Beans Persistent Timer 4.0 (enterpriseBeansPersistentTimer-4.0)
Jakarta Messaging 3.0 (messaging-3.0, messagingClient-3.0, messagingServer-3.0, messagingSecurity-3.0)

These join the Jakarta EE 9 features in previous Open Liberty betas:

Jakarta Password Utilities 1.0 (passwordUtilities-1.0)
Jakarta Connectors 2.0 Inbound Security (connectorsInboundSecurity-2.0)
Jakarta WebSocket 2.0 (websocket-2.0; now with full CDI integration)
RESTful Web Services 3.0 (restfulWS-3.0 and restfulWSClient-3.0)
Jakarta Server Faces 3.0 (faces-3.0)
Jakarta Connectors 2.0 (connectors-2.0)
Jakarta Enterprise Beans 4.0 (enterpriseBeans-4.0)
Jakarta Enterprise Beans Remote 4.0 (enterpriseBeansRemote-4.0)
Jakarta Enterprise Beans Home 4.0 (enterpriseBeansHome-4.0)
Jakarta Enterprise Beans Lite 4.0 (enterpriseBeansLite-4.0)
Jakarta EE Application Client 9.0 (javaeeClient-9.0)
Jakarta Authentication 2.0 (jaspic-2.0)
Jakarta Authorization 2.0 (jacc-2.0)
Jakarta Persistence 3.0 (includes Eclipselink 3.0-RC1.) (jpa-3.0)
Jakarta XML Binding 3.0 (jaxb-3.0)
Jakarta Managed Beans 2.0 (managedBeans-2.0)
Jakarta Concurrency 2.0 (concurrent-2.0)
Jakarta Bean Validation 3.0 (beanValidation-3.0)
Jakarta Contexts and Dependency Injection 3.0 (cdi-3.0)
Message-Driven Beans 4.0 (mdb-4.0)
JDBC 4.2 & 4.3 (jdbc-4.2 & jdbc-4.3)
Jakarta Transactions 2.0 (transaction-2.0)
Jakarta JSON Binding 2.0 (jsonb-2.0)
Jakarta JSON Processing 2.0 (jsonp-2.0)
Jakarta Servlet 5.0 (servlet-5.0)
Jakarta Server Pages 3.0 (jsp-3.0 now pages-3.0)
Jakarta Expression Language 4.0 (el-4.0 now expressionLanguage-4.0)

Jakarta Faces Container 3.0

This feature is part of the Jakarta EE9 features. The largest change in this feature is it has been updated to support and reference the new jakarta namespace. Previously the jsfContainer features supported the javax namespace, but as part of Jakarta EE9, the packages were updated from javax to jakarta.

The Open Liberty facesContainer-3.0 allows developers to use their preferred Jakarta Server Faces API & Implementation, such a Mojarra, by bundling it with their application. Historically, this container feature has been named using the acronym jsf (such as jsfContainer-2.3). However, starting with Jakarta Faces Container 3.0, the feature name will now begin with faces to move away from the Oracle trademarked acronyms. Otherwise, developers can simply use the Open Liberty provided faces-3.0 feature which uses the Apache MyFaces API and Implementation.

The following feature can be included in your server.xml:

    <featureManager>
        <feature>facesContainer-3.0</feature>
    </featureManager>

Additional information about the Jakarta Server Faces 3.0 specification can be found here.

Jakarta Enterprise Beans Persistent Timer 4.0

The enterpriseBeansPersistentTimer-4.0 feature enables the use of persistent timers in Jakarta Enterprise Beans. Configuration is the same as the corresponding feature from Jakarta EE 8, ejbPersistentTimer-3.2. With this final Jakarta Enterprise Beans 4.0 feature, the full capabilities of Jakarta Enterprise Beans 4.0 are now available in beta.

Jakarta Messaging 3.0

The following features can be included in your server.xml:

 <featureManager>
       <feature>messagingClient-3.0</feature>
       <feature>mdb-4.0</feature>
       <feature>jndi-1.0</feature>
 </featureManager>

Additional information about the Jakarta Messaging 3.0 specification can be found here.

  <featureManager>
    <feature>jakartaee-9.0</feature>
  </featureManager>

Or you can add the Web Profile convenience feature to enable all of the Jakarta EE 9 Web Profile beta features at once:

  <featureManager>
    <feature>webProfile-9.0</feature>
  </featureManager>

Try it now

If you’re using Maven, here are the coordinates:

<dependency>
    <groupId>io.openliberty.beta</groupId>
    <artifactId>openliberty-jakartaee9</artifactId>
    <version>21.0.0.1-beta</version>
    <type>zip</type>
</dependency>

Or for Gradle:

dependencies {
    libertyRuntime group: 'io.openliberty.beta', name: 'openliberty-jakartaee9', version: '[21.0.0.1-beta,)'
}

Or take a look at our Downloads page.

Your feedback is welcomed

Let us know what you think on our mailing list. If you hit a problem, post a question on StackOverflow. If you hit a bug, please raise an issue.

Support for gRPC, Java SE 15, and Custom JNDI for Enterprise Beans (EJBs) in Open Liberty 20.0.0.12

Fri, 20 Nov 2020 00:00:00 +0000

In Open Liberty 20.0.0.12 we now support gRPC 1.0 and gRPC Client 1.0 features. gRPC is a "high-performance, open source universal RPC framework." We’ve also added support for custom JNDI (Java Naming and Directory Interface) for Enterprise Beans (EJBs). This allows you to use custom JDNI names for looking up and/or injecting enterprise beans. Another major addition for this release is support for running Open Liberty on Java SE 15, which is currently the latest version of Java SE.

In Open Liberty 20.0.0.12:

Provide and consume gRPC services from your web applications (gRPC Service 1.0 and gRPC Client 1.0)
Support for Custom JNDI Names for Enterprise Beans (Jakarta Enterprise Beans 1.x, 2.x, 3.x)
Support for Java SE 15
Significant bugs fixed in this release

View the list of fixed bugs in 20.0.0.12.

Run your apps using 20.0.0.12

If you’re using Maven, here are the coordinates:

<dependency>
    <groupId>io.openliberty</groupId>
    <artifactId>openliberty-runtime</artifactId>
    <version>20.0.0.12</version>
    <type>zip</type>
</dependency>

Or for Gradle:

dependencies {
    libertyRuntime group: 'io.openliberty', name: 'openliberty-runtime', version: '[20.0.0.12,)'
}

Or if you’re using Docker:

FROM open-liberty

Or take a look at our Downloads page.

Provide and consume gRPC services from your web applications (gRPC Service 1.0 and gRPC Client 1.0)

gRPC is a high-performance, open source universal RPC framework. gRPC support on Liberty allows developers to both provide and consume gRPC services from your web applications. The introduction of gRPC support in Open Liberty means you can now take advantage of the benefits of gRPC more easily than before. Those benefits include great performance, simple service definitions via Protocol Buffers, cross-platform and language support, and wide industry adoption.

These two features were previously only available in beta are now generally available:

grpc-1.0, which enables gRPC services, and
grpcClient-1.0, which enables the use of a gRPC client for outbound calls.

gRPC Service

The grpc-1.0 feature works by scanning web apps for gRPC service implementations, through implementors of io.grpc.BindableService. The web app must include the protocol buffer compiler-generated code for the services it intends to provide, and additionally the service class must provide a no-argument constructor. The web app does not need to include any core gRPC libraries; those are provided by the Liberty runtime. Once a gRPC service is scanned and started, it becomes accessible to remote gRPC clients on the configured HTTP ports.

gRPC Client

The grpcClient-1.0 feature provides applications with access to a Netty gRPC client, as well as the related libraries. A web app must provide a client implementation and stubs, and can make outbound calls with a io.grpc.ManagedChannel without needing to provide the supporting client libraries.

Try out gRPC

You can now try gRPC by either following the instructions in this GitHub repository’s README or following this basic Hello World service (add the grpc-1.0 feature to your server.xml):

package com.ibm.ws.grpc;

import com.ibm.ws.grpc.beans.GreetingBean;

import io.grpc.examples.helloworld.GreeterGrpc;
import io.grpc.examples.helloworld.HelloReply;
import io.grpc.examples.helloworld.HelloRequest;
import io.grpc.stub.StreamObserver;

public class HelloWorldService extends GreeterGrpc.GreeterImplBase {

    public HelloWorldService(){}

    @Override
    public void sayHello(HelloRequest req, StreamObserver<HelloReply> responseObserver) {
        HelloReply reply = HelloReply.newBuilder().setMessage("Hello " + req.getName()).build();
        responseObserver.onNext(reply);
        responseObserver.onCompleted();
    }
}

For this example, the application must provide the helloworld protobuf definition along with the protobuf compiler output. No additional libraries need to be provided with the application, and once it’s started the helloworld greeter service will be accessible on the server’s HTTP endpoints.

For a client example, a basic Servlet using gRPC can be defined using the grpcClient-1.0 feature with:

package com.ibm.ws.grpc;

import io.grpc.examples.helloworld.GreeterGrpc;
import io.grpc.examples.helloworld.HelloReply;
import io.grpc.examples.helloworld.HelloRequest;

import io.grpc.ManagedChannel;
import io.grpc.ManagedChannelBuilder;
...
@WebServlet(name = "grpcClient", urlPatterns = { "/grpcClient" }, loadOnStartup = 1)
public class GrpcClientServlet extends HttpServlet {

        ManagedChannel channel;
        private GreeterGrpc.GreeterBlockingStub greetingService;

        private void startService(String address, int port)
        {
            channel = ManagedChannelBuilder.forAddress(address , port).usePlaintext().build();
            greetingService = GreeterGrpc.newBlockingStub(channel);
        }

        private void stopService()
        {
            channel.shutdownNow();
        }

        @Override
        protected void doGet(HttpServletRequest reqest, HttpServletResponse response)
            throws ServletException, IOException
        {

            // set user, address, port params
        }

        @Override
        protected void doPost(HttpServletRequest request, HttpServletResponse response)
            throws ServletException, IOException
        {

        // grab user, address, port params
        startService(address, port);
        HelloRequest person = HelloRequest.newBuilder().setName(user).build();
        HelloReply greeting = greetingService.sayHello(person);

        // send the greeting in a response
        stopService();
        }
    }
}

As with the service example, the application must provide the helloworld protobuf definition along with the protobuf compiler output. All required gRPC client libraries are provided by the grpcClient-1.0 feature.

Support for Custom JNDI Names for Enterprise Beans (Jakarta Enterprise Beans 1.x, 2.x, 3.x)

Support for Custom JNDI Names for Enterprise Beans (EJBs) is an enhancement to all existing enterprise beans features that allows an application to configure and use custom JDNI names for looking up and/or injecting enterprise beans, or use legacy default JNDI names instead of the specification defined JNDI names.

Prior to this enhancement, Liberty only supported looking up enterprise beans using the specification defined JNDI names : java:global/<app>/<module>/<bean>!<interface> & variations for java:app and java:module. With this enhancement, and without any additional configuration, legacy default JNDI names are now available for use by applications to lookup and/or inject enterprise beans. Also, rather than using the defaults, a custom name for each EJB may be specified in the ibm-ejb-jar-bnd.xml file (or ibm-ejb-jar-bnd.xmi file for EJB 2.x and 1.x modules). These new JNDI name options are available in addition to the existing specification required names.

For EJB 3.x modules, the following defaults will be available if a custom name is not provided:

Short form local interfaces and homes ejblocal:<package.qualified.interface>
Short form remote interfaces and homes <package.qualified.interface>
Long form local interfaces and homes ejblocal:<component-id>#<package.qualified.interface>
Long form remote interfaces and homes ejb/<component-id>#<package.qualified.interface>

The component-id defaults to <application-name>/<module-jar-name>/<ejb-name>

Easier Migration for Enterprise Bean Applications

Custom JNDI name support for enterprise beans provides an easier migration path for applications from other platforms (including WebSphere traditional).

Prior to Java EE 6, the Enterprise Beans specification did not prescribe the JNDI names required for enterprise beans, so every platform provided platform specific default names and custom binding file formats. Since Liberty only supported the specification defined JNDI names, migrating applications from other platforms often requires code changes to modify the platform specific JNDI names to the newer specification defined names. Now, migration from other platforms is simplified because applications may be migrated without changing code, but instead migrating the other platform specific binding files to the new Liberty platform specific binding file format. In some cases, use of the new legacy default names may also allow applications to migrate to liberty without specifying custom JNDI names in a binding file.

Application Configuration details

Full details about the legacy default bindings provided, as well as the syntax for declaring custom JNDI names in the ibm-ejb-jar-bnd.xml file, including examples, may be found in this IBM Knowledge Center article.

Custom bindings may be configured for an application in the following three locations.

Specify Custom bindings in ibm-ejb-jar-bnd.xml for EJB 3.x

Following are examples of how to configure custom bindings for EJB 3.x beans in an EJB JAR module or WAR module in ibm-ejb-jar-bnd.xml

Specify a binding per interface:

   <session name="NoInterceptorBasicStateless">
      <interface class="com.ejbs.InventoryService" binding-name="ejb/Inventory"/>
   </session>

Specify a component id (a prefix for default long form bindings)

   <session name="AccountServiceBean" component-id="Dept549/AccountProcessor"/>

Simple binding name (one name used for both local and remote)

   <session name="AccountServiceBean" simple-binding-name="ejb/AccountService"/>

Local and Remote home specific binding names

   <session name="AccountServiceBean" local-home-binding-name="ejblocal:AccountService"/>
   <session name="AccountServiceBean" remote-home-binding-name="ejb/services/AccountService"/>

Specify Custom bindings in server.xml

Following is an example of how to configure custom bindings for EJB 3.x beans in an EJB JAR module or WAR module in server.xml in the <application> or <ejbApplication> elements:

   <ejbApplication location="EJBTest.jar">
      <ejb-jar-bnd>
         <session name="InventoryServiceBean">
            <interface class="com.ejbs.InventoryService" binding-name="ejb/Inventory"/>
         </session>
      </ejb-jar-bnd>
   </ejbApplication>

Specify Custom bindings in ibm-ejb-jar-bnd.xmi for EJB 1.x/2.x

Following is an example of how to configure custom bindings for EJB 1.x or 2.x beans in an EJB JAR module in ibm-ejb-jar-bnd.xmi

EJB 1.x and 2.x provide a single JNDI name that applies to both the remote and local home:

   <ejbBindings xmi:id="BeanBinding_8" jndiName="suite/r6x/base/misc/poollimits/SLCMTTxTimeoutHome">
      <enterpriseBean xmi:type="ejb:Session" href="META-INF/ejb-jar.xml#SLCMTTxTimeout"/>
   </ejbBindings>

For a bean with both a remote and local home, the above will provide the following custom bindings:

   Remote Home : suite/r6x/base/misc/poollimits/SLCMTTxTimeoutHome
   Local Home  : local:suite/r6x/base/misc/poollimits/SLCMTTxTimeoutHome

Feature configuration details

Support for custom and legacy default JNDI names is enabled by default for all Enterprise Bean (EJB) features. This support will not interfere with the existing specification defined java: support. However, it is possible to completely disable the new support with the following setting in server.xml:

    <ejbContainer bindToServerRoot="false"/>

It is also possible to disable just the legacy short form default JNDI name support (i.e. the bean is bound using the interface name) with the following setting in server.xml:

   <ejbContainer disableShortDefaultBindings="true"/>

Since the new support for custom JNDI names and legacy defaults provide alternative JNDI names, it is now possible to disable the EJB specification required JNDI names. This is done in server.xml as follows:

   <ejbContainer bindToJavaGlobal="false"/>

Finally, the following new configuration attribute on the <ejbContainer> element in open-liberty enables the failing application start when multiple beans are bound to the same JNDI name:

    <ejbContainer customBindingsOnError="FAIL"/>

Support for Java SE 15

Any official Java SE 15 release from AdoptOpenJDK, Oracle, or other OpenJDK vendors will work with Open Liberty. Although Java SE 15 is currently the latest available version, it is not a long-term supported release, with standard support scheduled to end in March 2021.

Keep in mind, Eclipse OpenJ9 typically offers faster startup times than Hotspot.

The primary features added in this release include:

JEP 379 Shenandoah: A Low-Pause-Time Garbage Collector
JEP 377 ZGC: A Scalable Low-Latency Garbage Collector
JEP 378 Text Blocks
JEP 384 Records (Second Preview)
JEP 360 Sealed Classes (Preview)

For more information on downloading a version of Java 15, see AdoptOpenJDK.net, Eclipse.org or OpenJDK.java.net.

For working with the server.env file in Open Liberty, see the Configuration Files section of the Open Liberty Server Configuration Overview documentation.

For more information on new features available in Java 15, see OpenJDK.

Significant bugs fixed in this release

We’ve spent some time fixing bugs. The following sections describe just some of the issues resolved in this release. If you’re interested, here’s the full list of bugs fixed in 20.0.0.12.

IllegalAccessError when using MP Rest Client with Java SE 15

There was a MP Rest Client failure when running with Java SE 15.. This was fixed by changing the visibility of the compareCustomStatus method to public. If you would like to know more about MP Rest Client check out our Consuming RESTful services with template interfaces and Consuming RESTful services asynchronously with template interfaces guides.
MP GraphQL does not scan JARs in WEB-INF/lib for GraphQL components

Classes annotated with things like @GraphQLApi, @Type, etc. or types referenced from root level queries that exist in JARs in the WEB-INF/lib directory were not processed. This meant that only classes in the WEB-INF/classes directory were processed by the MP GraphQL runtime.
Increased CPU when moving from Liberty 19.0.0.6 to newer releases

When moving from 19.0.0.6 to a newer release, there was an issue with an increase in CPU usage. This was caused by a fix for a previous issue which made the processing of the Audit feature’s method arguments to be performed whether the feature was enabled or not. This issue was fixed by undoing the previous change and fixing the original problem differently. For more details on Liberty’s performance, see this post.
Variables in include files not recognized after config update

We added support for using variables in include elements in 20.0.0.3. The changes required to support temporary resolution of variables during processing of configuration resulted in a bug where changes to variables may not be recognized during a configuration update. For more information take a look at our Server Configuration Overview.
Prevent jsonp-1.0 and jsonpContainer-1.1 features from both starting

When jsonp-1.0 and jsonContainer-1.1 were configured at the same time it would cause a cryptic CWWKE0702E error of:

CWWKE0702E: Could not resolve module: com.ibm.websphere.javaee.jsonp.1.0 [265]
Bundle was not resolved because of a uses constraint violation.

The error handling of this invalid configuration has been improved to give an error message of:

CWWKF0033E: The singleton features com.ibm.websphere.appserver.jsonpImpl-1.1.0 and com.ibm.websphere.appserver.jsonpImpl-1.0.0 cannot be loaded at the same time. The configured features jsonpContainer-1.1 and jsonp-1.0 include one or more features that cause the conflict. Your configuration is not supported; update server.xml to remove incompatible features.

Get Open Liberty 20.0.0.12 now

Available through Maven, Gradle, Docker, and as a downloadable archive.

JAX-RS and Open Liberty: BYO Jackson

Wed, 11 Nov 2020 00:00:00 +0000

Chances are that if you use JAX-RS 2.0 or 2.1 in Open Liberty, then you use JSON to format your data. If so, it’s equally likely that you use Jackson as your JSON provider. Open Liberty’s JAX-RS 2.0 implementation uses Jackson as its default JSON provider.

You might be wondering, That’s pretty cool, but how can I take advantage of Jackson in my application?

Good question! Open Liberty uses Jackson but intentionally doesn’t expose Jackson to user applications. If you want to use some of the cool features in Jackson, such as annotating fields to ignore or providing serialization processing instructions, just bring your own Jackson. In other words, package the Jackson JAX-RS provider JAR files in the WAR file of your application. You need the following JAR files:

The JacksonJsonProvider class is automatically registered if all of these JAR files are in the WEB-INF/lib directory of your WAR file. However, if you specify any classes in your Application subclass by using the getClasses() method or the getSingletons() method, as shown in the following example, then you need to register the JacksonJsonProvider class:

public class HelloWorldApplication extends Application {
    @Override
    public Set<Class<?>> getClasses() {
        Set<Class<?>> classes = new HashSet<>();
        // ...
        classes.add(JacksonJaxbJsonProvider.class);
        return classes;
    }
}

Automatic discovery and registration isn’t available in the JAX-RS Client APIs, so you need to explicitly register the JacksonJsonProvider class:

Client client = ClientBuilder.newClient().register(JacksonJsonProvider.class);

That’s it! Now Open Liberty’s JAX-RS implementation uses the Jackson provider from your application instead of the Jackson provider that’s built into Open Liberty. Your application can now use those cool Jackson features.

You don’t even need to do any classloading tricks, such as specifying your delegation as parentLast. The Open Liberty server doesn’t expose the Jackson API packages, so your application can load only the Jackson classes that you provide. The application also works regardless of the delegation policy, so you can use a parentLast delegation if you really want to.

If you’re interested in learning more about Jackson with Open Liberty, check out the sample.BYOJackson app at the WASdev GitHub repo. By the way, Jackson isn’t the only Java-to-JSON converter that you can choose. If you’re using JAX-RS 2.1, then you can also use JSON-B to get Java-to-JSON (and vice versa) conversion magic provided by Open Liberty. To enable JSON-B, see the JavaScript Object Notation Binding 1.0 feature documentation.

More MicroProfile 4.0 previews, MicroProfile LRA, and more Jakarta EE 9 features in Open Liberty 20.0.0.12-beta

Tue, 27 Oct 2020 00:00:00 +0000

Open Liberty 20.0.0.12-beta comes with previews of a range of MicroProfile updates, and support for Java SE 15. The MicroProfile updates include more features in MicroProfile 4.0 (MicroProfile Config 2.0 and MicroProfile JWT 1.2), as well as the new MicroProfile LRA. Also available for preview are a multitude of Jakarta EE 9 features amongst which are changes to the Jakarta RESTful Web Services specification and the addition of message-driven bean support.

We have two beta packages for Open Liberty:

All Beta Features: a larger package that contains all Open Liberty beta features (including Jakarta EE 9 beta features) and GA features and functions.
Jakarta EE 9 Beta Features: a lightweight package that contains only the Jakarta EE 9 features.

This means that you can now try out our in-development Open Liberty features by just adding the relevant coordinates to your build tools.

If you try either package, let us know what you think.

All Beta Features package

The All Beta Features package includes the following beta features:

New features in MicroProfile 4.0
- New capabilities (Config Profile, Config Properties, ConfigValue support, and more) in MicroProfile Config (MicroProfile Config 2.0)
- New configuration properties for MicroProfile JWT (MicroProfile JWT 1.2)
Enable loosely-coupled services to coordinate long running activities (MicroProfile LRA Participants 1.0 & MicroProfile LRA Coordinator 1.0)
Support for Java SE 15

New features in MicroProfile 4.0

Open Liberty 20.0.0.12-beta provides another two feature updates for MicroProfile 4.0:

MicroProfile Config 2.0
MicroProfile JWT 1.2

Other MicroProfile 4.0 features were part of earlier betas:

MicroProfile OpenAPI 2.0 (20.0.0.11-beta)
MicroProfile Fault Tolerance 3.0 (20.0.0.10-beta)
MicroProfile Metrics 3.0 (20.0.0.10-beta)
MicroProfile Health 3.0 (20.0.0.10-beta)
MicroProfile OpenTracing 2.0 (20.0.0.10-beta)

While we’d hoped to also include MicroProfile Rest Client 2.0 (also part of MicroProfile 4.0), we didn’t quite make it this time so it will make its debut in a future beta. However, if you just can’t wait until then, you can always give the feature a try in one of our nightly builds.

To enable all the available MicroProfile 4.0 features at once, just add our MicroProfile 4.0 convenience feature to your server.xml:

   <featureManager>
       <feature>microProfile-4.0</feature>
   </featureManager>

For more information about the MicroProfile updates included in this milestone, visit the release page.

New capabilities (Config Profile, Config Properties, ConfigValue support, and more) in MicroProfile Config (MicroProfile Config 2.0)

MicroProfile Config enables application configuration from different locations (ConfigSources). MicroProfile Config 2.0 in Open Liberty consumes SmallRye’s implementation of the specification.

MicroProfile Config 2.0 is a major version release (from 1.4) which introduces Functional and API/SPI changes in Microprofile Config 2.0.

Functional Changes

Provides a way to retrieve a number of related configuration properties with a specified prefix into a CDI bean, using the @ConfigProperties annotation.
```
@ConfigProperties(prefix="customer")
@Dependent
public static class BeanOne {
   private String name;
   int age;
}
```
The code above retrieves the following defined properties for the name and age fields:
```
customer.name=Bob
customer.age=24
```
Allows you to easily determine which was the "winning" ConfigSource (the ConfigSource with the highest ordinal) for a specified property via ConfigValue. A ConfigValue object holds information about the configuration property name, configuration value, the ConfigSource name from where the configuration property was loaded and the ordinal of the ConfigSource. You can access these values with the following method:
```
ConfigValue cv = Config.getConfigValue(String propertyName);
cv.getSourceName() // the config source that supplies the configure value for the above property
```
Enables an application to include configuration for different environments and development stages while only one of them is active (e.g. dev, test, prod) using configuration profiles. The config profile can be specified using the mp.config.profile property, which can be set in any of the configuration sources. Once it is set, the corresponding properties associated with the active profile are used. The value can also be set at application start-up, for example:
```
java -jar myapp.jar -Dmp.config.profile=testing
```
The mp.config.profile property works on both the property level and config file level:

On the property level profiles can be used by setting Config property values specific to the selected profile. For example, the vehicle.name property in the following example would be set to bike from the previous Config start-up command:
```
%dev.vehicle.name=car
%testing.vehicle.name=bike
vehicle.name=lorry
```
If mp.config.profile was not set, vehicle.name would be set to lorry.

On the config file (microprofile-config.property) level the property mp.config.profile also activates the corresponding microprofile-config-<mp.config.profile>.properties with microprofile-config.properties as the fallback.
Supports Property Expressions, which provide a way to set and expand variables in property values. For example, in the following configuration properties, the property server.url will be resolved to http://example.org/endpoint:
```
server.url=http://${server.host}/endpoint
server.host=example.org
```
Previous working configurations might behave differently if the configuration in use contains values with Property Expressions syntax.
Two new methods have been introduced to Config.java:
- Config.getValues(String propertyName, Class<T> propertyType)
- Config.getOptionalValues(String propertyName, Class<T> propertyType)
  
  The methods have been added to enable you to retrieve multi-valued properties as lists instead of arrays. The methods return the resolved property values with the specified propertyType for the specified propertyName.
OptinalInt, OptionalLong and OptionalDouble are now provided as built-in Converters. The new Converters can be used like any of the other built-in Converters, converting injected Config property values to a defined type:
```
@Inject
@ConfigProperty(name = "my.optional.int.property")
private OptionalInt optionalIntProperty;
```

Incompatible changes

If you move up from MicroProfile Config 1.x to 2.0, please take care of the following incompatible changes:

ConfigSource.getPropertyNames is no longer a default method. The implementation of a ConfigSource must implement this method.
Previous versions of the specification would not evaluate property expressions. As such, previous working configuration may behave differently (if the used configuration contains values with property expressions syntax). property expressions can be disabled by setting the property mp.config.property.expressions.enabled with the value of false.
Empty values or other special characters are no longer valid Config property values. This means that Config.getValue(String propertyName, Class<T> propertyType) will never return null; a NoSuchElementException will be thrown if either a Config property value is not defined, is defined as an empty string, or its converter returns null. In the previous release, the empty value was returned as an empty value. For more information, please refer to this section of the spec.

To enable the new beta features in your app, add them to your server.xml:

<featureManager>
   <feature>cdi-2.0</feature> <!-- required for supporting configuration injection -->
   <feature>mpConfig-2.0</feature>
</featureManager>

For more information:

New configuration properties for MicroProfile JWT (MicroProfile JWT 1.2)

With MicroProfile JSON Web Token (JWT) 1.2 you can use a JWT token for authenticating and authorizing requests to a service. MicroProfile JWT 1.2 simplifies the configuration for managing the validation of the JWT by introducing new MicroProfile Config properties. Enhanced signature algorithm support is added in this Open Liberty beta.

MicroProfile JSON Web Token 1.2 adds the following MicroProfile Config properties to control different aspects of the JWT validation.

mp.jwt.token.header

The mp.jwt.token.header property allows you to control the HTTP request header which is expected to contain a JWT token. You can specify either Authorization (default) or Cookie values.

The mp.jwt.token.cookie property allows you to specify the name of the cookie which is expected to contain a JWT token. The default value is Bearer if not specified.

mp.jwt.verify.audiences

The mp.jwt.verify.audiences property allows you to create a list of allowable audience (aud) values. At least one of these must be found in the claim. Previously, this had to be configured in the server.xml file. Now, you can configure the audiences in the MicroProfile Config property as follows:

mp.jwt.verify.audiences=conferenceService

mp.jwt.verify.publickey.algorithm

The mp.jwt.verify.publickey.algorithm property allows you to control the Public Key Signature Algorithm that is supported by the MicroProfile JWT endpoint. The default value is RSA256 if not specified. Previously, this had to be configured in the server.xml file. Now, you can configure the public key algorithm used for verification of the JWT in the MicroProfile Config property as follows:

mp.jwt.verify.publickey.algorithm=ES256

The specification also adds support for the ES256 signature algorithm, while this Open Liberty beta supports using the RS384, RS512, HS384, HS512, ES256, ES384, and the ES512 signature algorithms.

To enable the the MicroProfile JWT 1.2 feature in your app, add the feature to your server.xml:

   <featureManager>
       <feature>mpJwt-1.2</feature>
   </featureManager>

For more information:

Enable loosely-coupled services to coordinate long running activities (MicroProfile LRA Participants 1.0 & MicroProfile LRA Coordinator 1.0)

Long Running Actions (LRA) provide a cloud-native transaction model based on a compensating Saga system. This allows loosely coupled services to coordinate long running activities, guaranteeing eventual data consistency without the need to put locks on data.

Two features have been provided for LRA support, a Coordinator feature and a Participant feature:

The Coordinator is a dedicated service with which participant microservices implicitly register their LRA’s through the use of annotations. It has the responsibility of driving actions such as completing or compensating on an LRA.
A Participant is a JAX-RS microservice that wishes to participate in an LRA and has been annotated appropriately.

In order for an LRA to be used a single instance of the Coordinator feature must be enabled which will start a Coordinator application. Then a participating mircoservice must be written with the Participant feature enabled to allow the LRA annotations to be used.

To start or join an LRA use the @LRA annotation. Depending on the type provided it may create a new LRA, join the existing LRA or continue outside one if none is provided. A full list of options can be found in the Microprofile Long Running Actions specification.

An example of always creating a new LRA when called would be:

    @LRA(LRA.Type.REQUIRES_NEW)
    @Path(“/start”)
    @PUT
    public Response startAction(@HeaderParam(LRA_HTTP_CONTEXT_HEADER) URI lraId)
    {
        /*
         * Business logic that may call upon other services to participate in this Long Running Action
         */
         return Response.ok().build();
    }

Once the LRA has been successfully finished all participating services will have their @Complete annotated methods called to perform the necessary cleanup:

    @Complete
    @Path("/complete")
    @PUT
    public Response completeAction(@HeaderParam(LRA_HTTP_CONTEXT_HEADER) URI lraId)
    {
        /*
         * Business logic to cleanup resources once the LRA has closed successfully
         */
         return Response.ok().build();
    }

Should a service in an LRA be canceled or timeout, the @Compensate methods for each participating service in the LRA will be called:

    @Compensate
    @Path("/compensate")
    @PUT
    public Response compensateAction(@HeaderParam(LRA_HTTP_CONTEXT_HEADER) URI lraId)
    {
        /*
         * As the LRA has been canceled business logic to compensate any changes is necessary
         */
         return Response.ok().build();
    }

To enable the LRA Coordinator feature in your app, add the feature to your server.xml:

<featureManager>
    <feature>cdi-2.0</feature>
    <feature>jaxrs-2.1</feature>
    <feature>mpLRACoordinator-1.0</feature>
</featureManager>

To enable the LRA Participants feature in your app, add the feature to your server.xml:

<featureManager>
    <feature>cdi-2.0</feature>
    <feature>jaxrs-2.1</feature>
    <feature>mpLRA-1.0</feature>
</featureManager>

<lra port=“<port>” host=<hostname> path="lrac" />

Where <port> is the default HTTP port of the Open Liberty server with the Coordinator feature is enabled, and <hostname> is the hostname provided for that Open Liberty server.

MicroProfile Long Running Actions is not a part of the MicroProfile 4.0 specification, and so needs to be explicitly added as a feature to be used.

For more information:

Microprofile Long Running Actions Specification

Support for Java SE 15

Any official Java SE 15 release from AdoptOpenJDK, Oracle, or other OpenJDK vendor will work with Open Liberty. Java SE 15 is not a long-term supported release, with standard support scheduled to end in March 2021.

Keep in mind, Eclipse OpenJ9 typically offers faster startup times than Hotspot.

The primary features added in this release include:

JEP 379 Shenandoah: A Low-Pause-Time Garbage Collector
JEP 377 ZGC: A Scalable Low-Latency Garbage Collector
JEP 378 Text Blocks
JEP 384 Records (Second Preview)
JEP 360 Sealed Classes (Preview)

For more information on downloading a version of Java 15, see AdoptOpenJDK.net, Eclipse.org or OpenJDK.java.net.

For working with the server.env file in Open Liberty, see the Configuration Files section of the Open Liberty Server Configuration Overview documentation.

For more information on new features available in Java 15, see OpenJDK.

Try it now

To try out these features, just update your build tools to pull the Open Liberty All Beta Features package instead of the main release. The beta works with Java SE 15, Java SE 11, or Java SE 8.

If you’re using Maven, here are the coordinates:

<dependency>
  <groupId>io.openliberty.beta</groupId>
  <artifactId>openliberty-runtime</artifactId>
  <version>20.0.0.12-beta</version>
  <type>pom</type>
</dependency>

Or for Gradle:

dependencies {
    libertyRuntime group: 'io.openliberty.beta', name: 'openliberty-runtime', version: '[20.0.0.12-beta,)'
}

Or take a look at our Downloads page.

Jakarta EE 9 Beta Features package

The main change visible to developers in Jakarta EE is the names of packages changing to accommodate the new jakarta.* namespace. In this Open Liberty beta, we have a number of new API Release Candidates to join the expanding library of supported Jakarta packages.

This Open Liberty beta introduces the following Jakarta EE 9 features which now possess their all-new Jakarta EE 9 package names:

Jakarta WebSocket 2.0 (websocket-2.0; now with full CDI integration)
Enterprise Beans Remote Client 2.0 (ejbRemoteClient-2.0)
RESTful Web Services 3.0 (restfulWS-3.0 and restfulWSClient-3.0)
Jakarta Server Faces 3.0 (faces-3.0)
Jakarta Connectors 2.0 (connectors-2.0)

These join the Jakarta EE 9 features in previous Open Liberty betas:

Jakarta Enterprise Beans Remote 4.0 (ejbRemote-4.0)
Jakarta EE Application Client 9.0 (javaeeClient-9.0)
Jakarta Authentication 2.0 (jaspic-2.0)
Jakarta Authorization 2.0 (jacc-2.0)
Jakarta Persistence 3.0 (includes Eclipselink 3.0-RC1.) (jpa-3.0)
Jakarta XML Binding 3.0 (jaxb-3.0)
Jakarta Managed Beans 2.0 (managedBeans-2.0)
Jakarta Concurrency 2.0 (concurrent-2.0)
Jakarta Enterprise Beans Home 4.0 (ejbHome-4.0)
Jakarta Enterprise Beans Lite 4.0 (ejbLite-4.0)
Jakarta Bean Validation 3.0 (beanValidation-3.0)
Jakarta Contexts and Dependency Injection 3.0 (cdi-3.0)
JDBC 4.2 & 4.3 (jdbc-4.2 & jdbc-4.3)
Jakarta Transactions 2.0 (transaction-2.0)
Jakarta JSON Binding 2.0 (jsonb-2.0)
Jakarta JSON Processing 2.0 (jsonp-2.0)
Jakarta Servlet 5.0 (servlet-5.0)
Jakarta Server Pages 3.0 (jsp-3.0)
Jakarta Expression Language 4.0 (el-4.0)

  <featureManager>
    <feature>jakartaee-9.0</feature>
  </featureManager>

Or you can add the Web Profile convenience feature to enable all of the Jakarta EE 9 Web Profile beta features at once:

  <featureManager>
    <feature>webProfile-9.0</feature>
  </featureManager>

Try it now

If you’re using Maven, here are the coordinates:

<dependency>
    <groupId>io.openliberty.beta</groupId>
    <artifactId>openliberty-jakartaee9</artifactId>
    <version>20.0.0.12-beta</version>
    <type>zip</type>
</dependency>

Or for Gradle:

dependencies {
    libertyRuntime group: 'io.openliberty.beta', name: 'openliberty-jakartaee9', version: '[20.0.0.12-beta,)'
}

Or take a look at our Downloads page.

Your feedback is welcomed

Let us know what you think on our mailing list. If you hit a problem, post a question on StackOverflow. If you hit a bug, please raise an issue.

MicroProfile OpenAPI 2.0 preview plus new features and loads of improvements for Jakarta EE 9 in Open Liberty 20.0.0.11-beta

Tue, 29 Sep 2020 00:00:00 +0000

In 20.0.0.11-beta we have a preview of MicroProfile OpenAPI 2.0, which enables you to generate documentation directly from APIs. We have also added two new Jakarta EE 9 features, along with improvements to existing Jakarta EE 9 features, many moving up to the latest API Release Candidates.

We have two beta packages for Open Liberty:

All Beta Features: a new, larger package that contains all Open Liberty beta features (including Jakarta EE 9 beta features) and GA features and functions.
Jakarta EE 9 Beta Features: a lightweight package that contains only the Jakarta EE 9 features.

This means that you can now try out our in-development Open Liberty features by just adding the relevant coordinates to your build tools.

If you try either package, let us know what you think.

All Beta Features package

The All Beta Features package includes MicroProfile OpenAPI 2.0.

MicroProfile OpenAPI 2.0

MicroProfile OpenAPI 2.0 builds on top of the OpenAPI v3 specification. The OpenAPI v3 specification defines a standard, language-agnostic, interface for describing REST APIs which allows documentation to be generated from the APIs themselves. The MicroProfile OpenAPI specification provides a unified Java API for the OpenAPI v3 specification which allows Java developers to generate OpenAPI v3 documents from their JAX-RS applications. MicroProfile OpenAPI 2.0 introduces some new annotations that simplify the process of generating OpenAPI documentation for your REST APIs. It also introduces a new MicroProfile Config property prefix that can be used to define the schema for Java classes that you do not have the source code for.

@SchemaProperty

The @SchemaProperty annotation has been added to allow you to include properties in the definition of a schema when using the @Schema annotation. Previously, the @Schema annotation did not allow you to define any properties. Properties were introspected from the implementation class. With the introduction of the @SchemaProperty annotation, a list of properties can now defined using the properties attribute on the @Schema annotation, as follows:

@Schema(
    name = "User",
        description = "Telephone number to contact the user”,
        implementation = User.class,
        properties = {
            @SchemaProperty(
                name = "phone",
                description = "Telephone number to contact the user”
            )
        }
    )}

@RequestBodySchema

The @RequestBodySchema annotation has been added to provide a shorthand mechanism to specify the schema for a request body. Previously, defining the schema for a request body required the use of three different annotations, as follows:

@RequestBody(
    content = {
        @Content(
            schema = @Schema(
                implementation = MyRequestObject.class
            )
        )
    }
)

With the introduction of the @RequestBodySchema annotation, this can be simplified to the following single annotation:

@RequestBodySchema(MyRequestObject.class)

@APIResponseSchema

The @APIResponseSchema annotation has been added to provide a shorthand mechanism to specify the schema for a response body. Previously, defining the schema for a response body required the use of three different annotations, as follows:

@APIResponse(
    content = {
            @Content(
                schema = @Schema(
                    implementation = MyResponseObject.class
                )
            )
        }
    )

With the introduction of the @RequestBodySchema annotation, this can be simplified to the following single annotation:

@APIResponseSchema(MyResponseObject.class)

mp.openapi.schema.*

The mp.openapi.schema.* MicroProfile Config property prefix has been added to allow you to define the schema for Java classes using configuration rather than code. The use of this property is functionally equivalent to the use of the @Schema annotation on a Java class, but may be used in cases where you do not have access to the source code of a class. The remainder of the property key must be the fully-qualified class name and the value must be a valid OpenAPI schema object, specified in the JSON format. For example, in the case where an application needs to represent dates in epoch milliseconds, the following configuration could be used (line escapes and indentation added for readability):

mp.openapi.schema.java.util.Date = { \
   "name": "EpochMillis" \
   "type": "number", \
   "format": "int64", \
   "description": "Milliseconds since January 1, 1970, 00:00:00 GMT" \
 }

Enable OpenAPI 2.0 in the server.xml, along with any other features you’re using.

<featureManager>
    <feature>mpOpenAPI-2.0</feature>
</featureManager>

For more information:

Try it now

To try out these features, just update your build tools to pull the Open Liberty All Beta Features package instead of the main release. The beta works with Java SE 14, Java SE 11, or Java SE 8.

If you’re using Maven, here are the coordinates:

<dependency>
  <groupId>io.openliberty.beta</groupId>
  <artifactId>openliberty-runtime</artifactId>
  <version>20.0.0.11-beta</version>
  <type>pom</type>
</dependency>

Or for Gradle:

dependencies {
    libertyRuntime group: 'io.openliberty.beta', name: 'openliberty-runtime', version: '[20.0.0.11-beta,)'
}

Or take a look at our Downloads page.

Jakarta EE 9 Beta Features package

The main change you should be aware of in Jakarta EE 9 is the names of packages changing to accomodate the new jakarta.* namespace. In this Open Liberty beta, we have more Jakarta EE 9 features with their name change completed. Most features have improvements too, including many moving up to the latest API Release Candidates.

This Open Liberty beta introduces the following Jakarta EE 9 features which now possess their all-new Jakarta EE 9 package names:

Jakarta Enterprise Beans Remote 4.0 (ejbRemote-4.0)
Jakarta EE Application Client 9.0 (javaeeClient-9.0) (now supports Jakarta Enterprise Beans Remote Client 4.0)

These join the Jakarta EE 9 features in previous Open Liberty betas:

Jakarta Authentication 2.0 (jaspic-2.0)
Jakarta Authorization 2.0 (jacc-2.0)
Jakarta Persistence 3.0 (includes Eclipselink 3.0-RC1.) (jpa-3.0)
Jakarta XML Binding 3.0 (jaxb-3.0)
Jakarta Managed Beans 2.0 (managedBeans-2.0)
Jakarta Concurrency 2.0 (concurrent-2.0)
Jakarta Enterprise Beans Home 4.0 (ejbHome-4.0)
Jakarta Enterprise Beans Lite 4.0 (ejbLite-4.0)
Jakarta Bean Validation 3.0 (beanValidation-3.0)
Jakarta Contexts and Dependency Injection 3.0 (cdi-3.0)
Jakarta WebSocket 2.0 (websocket-2.0; currently the integration with CDI is not complete)
JDBC 4.2 & 4.3 (jdbc-4.2 & jdbc-4.3)
Jakarta Transactions 2.0 (transaction-2.0)
Jakarta JSON Binding 2.0 (jsonb-2.0)
Jakarta JSON Processing 2.0 (jsonp-2.0)
Jakarta Servlet 5.0 (servlet-5.0)
Jakarta Server Pages 3.0 (jsp-3.0)
Jakarta Expression Language 4.0 (el-4.0)

<featureManager>
    <feature>jakartaee-9.0</feature>
</featureManager>

Or you can add the Web Profile convenience feature to enable all of the Jakarta EE 9 Web Profile beta features at once:

<featureManager>
    <feature>webProfile-9.0</feature>
</featureManager>

Or take a look at our Downloads page.

Try it now

If you’re using Maven, here are the coordinates:

<dependency>
    <groupId>io.openliberty.beta</groupId>
    <artifactId>openliberty-jakartaee9</artifactId>
    <version>20.0.0.11-beta</version>
    <type>zip</type>
</dependency>

Or for Gradle:

dependencies {
    libertyRuntime group: 'io.openliberty.beta', name: 'openliberty-jakartaee9', version: '[20.0.0.11-beta,)'
}

Your feedback is welcomed

Let us know what you think on our mailing list. If you hit a problem, post a question on StackOverflow. If you hit a bug, please raise an issue.

With our new reactive guides, that makes 50!

Thu, 24 Sep 2020 00:00:00 +0000

We recently published a series of guides on how to write reactive Java microservices. There are currently five reactive guides, four on writing the code and one on testing it in true-to-production environments. This brings our total number of Open Liberty guides to more than 50, which we are rather proud of in just three years, considering the amount of work and quality-checking that goes into each of them.

If you’d like to find out more about our new reactive guides, read on. If you’re not already familiar with the Open Liberty guides already, we’ll start with a brief introduction…

What are guides?

The Open Liberty guides are similar to tutorials but, instead of asking you to work through a set of step-by-step instructions with no explanation of the code you’re constructing, the guides take an aspect of a simple web services application and talk you through how you’d build it yourself, explaining how the code works as you go. You can complete a guide in just 15 mins or so.

Each guide has two copies of a simple application in its GitHub repository: a finish version, which you can just run to see what it does, and a start version, which has pieces of the application missing. As you work through the guide, you create the missing pieces of the start version, which can include, for example, adding one or more Java classes, adding a server configuration, or updating a Maven configuration. All the code is provided for you so you can be confident that what you create will work at the end.

The guides assume no prior knowledge of a topic, and they take you from beginning to end (but if you’re intermediate, just use the Table of Contents to skip forward to a specific part). Prerequisites are also kept to a minimum. And if you don’t want to bother with any code on your local machine, take a look at our interactive guides which require only a browser:

When you’ve finished working through the guide as a tutorial, you can then take the code from the example application and continue learning by adapting or extending the code for your own purposes. Alternatively, if you’re just looking for code examples, you can just browse the guide’s GitHub repository for code similar to what you need and read how it works in the guide.

Learning with guides

We recently published a new series of guides about writing reactive microservices using MicroProfile Reactive Messaging. These reactive messaging guides take a similar approach to our existing guides and demonstrate how to write simple web services with a reactive architecture.

The first in the reactive series of guides looks at how to create reactive Java microservices. It takes a simple reactive messaging app and shows you how to build it:

The guide introduces the concepts that you need to understand to follow the guide. In this case, it gives a brief introduction to asynchronous messaging between microservices and how MicroProfile Reactive Messaging makes it easy to asynchronously send, receive, and process messages when they’re received as continuous streams of events.

The guide then takes you through each of the main classes for the services in the application and explains the key parts of how the code works. You can copy the code to the partial application in the GitHub repository’s start directory to build the app as you read. The guide then shows you how to build, run, and test it.

After that, you can play with the code by yourself and adapt it for your own purposes or move on to another of the guides. Each guide focuses on a single aspect of writing reactive Java microservices.

The new reactive series contains the following guides:

Learning to write cloud-native Java microservices

The new reactive guides are just the latest of more than 50 developer guides that we’ve published on the Open Liberty website over the past three years. Many of the guides cover topics relating to how to develop cloud-native Java applications, in particular using Eclipse MicroProfile technologies, including:

Creating a RESTful web service using JAX-RS and JSON-B.
Consuming a RESTful web service using MicroProfile Rest Client.
Documenting RESTful APIs using MicroProfile OpenAPI.
Configuring microservices using MicroProfile Config.
Building fault-tolerant microservices with the @Fallback annotation using MicroProfile Fault Tolerance.
Providing metrics from a microservices using MicroProfile Metrics.
Enabling distributed tracing in microservices with Jaeger.
Securing microservices with JSON Web Tokens using MicroProfile JWT.
Authenticating users through social media providers.

There is also a selection of interactive MicroProfile guides which are all browser-based and focus on explaining the concepts in an interactive way, including:

Separating configuration from code in microservices using MicroProfile Config.
Preventing repeated failed calls to microservices using MicroProfile Fault Tolerance’s Circuitbreaker and Fallback policies.

Beyond MicroProfile, there are guides on complementary technologies for writing cloud-native Java applications using established Jakarta EE technologies, including:

Securing a web application using Jakarta EE Security.
Accessing and persisting data in microservices using JPA.

The guides cover the whole developer lifecycle including building an application with Maven or Gradle, testing the application, containerizing the application, and then deploying the application to one of several commercial cloud platforms, including IBM Cloud, Red Hat OpenShift, and Microsoft Azure.

Will there be more new guides?

Our guides have been really well-received so we’re not stopping at 50. We have a large backlog of proposed guides, some of which we’re already working on and are nearly ready to publish, on topics such as using the Open Liberty Operator, securing applications with OpenID Connect, and accessing data in MongoDB.

Get involved

You’re welcome to propose new guides by raising an issue and writing an outline for consideration. Especially let us know if you can contribute in some way once the guide has been accepted, whether that’s by writing the guide, writing some code, or both.

If you see any errors in our existing guides, feel free to raise an issue against that guide’s GitHub repository (each guide has its own repository, which you can find in the guide text) or to create a PR to fix it.

In the meantime though, grab a hot drink and browse our 50+ guides. To stay up to date with our new guides, follow us on Twitter or bookmark new guides.

Pre-populating database connections for better response times in the cloud

Wed, 09 Sep 2020 00:00:00 +0000

In modern cloud environments we often use lightweight and disposable instances of our applications, as opposed to long-lived instances. This methodology is sometimes called "scale up vs. scale out", and sometimes it is called "cattle, not pets". The main idea here is that we should expect application instances to be disposed of if they stop working or are no longer needed, or more importantly, that we can easily make more instances if we need more.

When we apply the "cattle, not pets" methodology to applications that use database connections, we realize that the default behavior of lazily getting new connections as requests come in may not provide the best response times for our users.

CDI to the rescue!

To alleviate this problem, we can "pre-populate" (or "pre-warm") the database connection pool by eagerly obtaining a number of connections immediately once the application instance starts. Some frameworks have proprietary ways of doing this, but there is also a standard way of doing so that will work for any Java EE-, Jakarta EE- or MicroProfile-compliant runtime:

import java.sql.Connection;
import java.sql.SQLException;
import java.util.ArrayList;
import java.util.List;

import javax.annotation.Resource;
import javax.enterprise.context.ApplicationScoped;
import javax.enterprise.context.Initialized;
import javax.enterprise.event.Observes;
import javax.inject.Inject;
import javax.sql.DataSource;

import org.eclipse.microprofile.config.inject.ConfigProperty;

@ApplicationScoped
public class ConnectionWarmer {

  @Inject
  @ConfigProperty(name = "DB_PREWARM_CONNECTIONS", defaultValue = "5")
  int preWarmConnections;

  @Resource(lookup = "jdbc/myDB", shareable = false)
  DataSource ds;

  private volatile boolean isWarm = false;

  public boolean isWarm() {
    return isWarm;
  }

  public void warmConnections(@Observes @Initialized(ApplicationScoped.class) Object context) throws Exception {
    if (preWarmConnections < 1)
      return;

    System.out.println("Pre-populating " + preWarmConnections + " DB connections");

    List<Connection> connections = new ArrayList<>();
    try {
      for (int i = 0; i < preWarmConnections; i++) {
        connections.add(ds.getConnection());
      }
    } finally {
      connections.forEach(this::closeQuietly);
    }

    isWarm = true;
    System.out.println("Done pre-populating " + preWarmConnections + " connections");
  }

  private void closeQuietly(Connection con) {
    try {
      con.close();
    } catch (SQLException ignore) {
    }
  }
}

To accomplish this we are using a few tricks:

Using @Observes @Initialized(ApplicationScoped.class) from CDI, we can create a method that is triggered as soon as the application starts.
Using @ConfigProperty(name = "DB_PREWARM_CONNECTIONS", defaultValue = "5") from MicroProfile Config, we define externalized configuration for how many connections to pre-populate, with a default value of 5 connections to pre-populate.
Using @Resource(lookup = "jdbc/myDB", shareable = false) from Common Annotations, we can inject the datasource used by our application and define it as shareable = false which will ensure that each getConnection() request in the sequence will obtain a new physical database connection. The default value is shareable = true which would cause all 5 connections to re-use the same physical database connection (normally efficient, but not what we want in this case).

Waiting to serve requests until the connection pool is warm

Getting a number of connections right away when the application starts is only half of the solution. We also want our application to wait to report that it’s ready until the necessary number of connections have been pre-populateed. To accomplish this, we can add a readiness check from MicroProfile Health like so:

import javax.enterprise.context.ApplicationScoped;
import javax.inject.Inject;

import org.eclipse.microprofile.health.HealthCheck;
import org.eclipse.microprofile.health.HealthCheckResponse;
import org.eclipse.microprofile.health.Readiness;

@Readiness
@ApplicationScoped
public class WarmConnectionsReady implements HealthCheck {

  @Inject
  ConnectionWarmer warmer;

  @Override
  public HealthCheckResponse call() {
    return HealthCheckResponse.named("DB connections warm")
        .state(warmer.isWarm())
        .build();
  }

}

Using this readiness check, the entire application/container waits to report it is ready until the DB connections have been pre-populateed when the cloud infrastructure polls the readiness URL of: http://localhost:9080/health/ready

Try it out!

The complete code mentioned in this post can be found in my sample repository:

# clone the repo
$ git clone git@github.com:aguibert/basic-liberty-mvn.git -b datasource-prewarm
cd basic-liberty-mvn

# in a separate terminal window, start DB2
cd /path/to/basic-liberty-mvn
./startDB2.sh

# in the original terminal window run the app
mvn liberty:dev

Securing Open Liberty applications with Azure Active Directory using OpenID Connect

Fri, 04 Sep 2020 00:00:00 +0000

Long gone are the days when you had to create your own user account management, authentication, and authorization for your web delivered software. Instead, contemporary applications make use of Identity and Access Management (IAM) services from external providers. As a full-featured Java application runtime, Open Liberty has great options for externally provided IAM.

Open Liberty supports IAM mainstays, such as Social Media Login, SAML Web Single Sign-on, and OpenID Connect Client. In Bruce Tiffany’s blog post “Securing Open Liberty apps and micro-services with MicroProfile JWT and Social Media login,” you have a solid example of how to use the Open Liberty Social Media Login feature to authenticate users using their existing social media credentials. In this blog post, let’s take a look at another example of how to configure the Liberty Social Media Login feature as an OpenID Connect client to secure Java applications with Azure Active Directory.

The sample code used in this blog is hosted on this GitHub repository. Feel free to check it out and follow its user guide to run the Java EE demo application before or after reading this blog.

Set up Azure Active Directory
Configure social media login as OpenID Connect client
Use OpenID Connect to authenticate users
Workflow
Secure internal REST calls using JWT RBAC
Summary

Set up Azure Active Directory

Azure Active Directory (Azure AD) implements OpenID Connect (OIDC), an authentication protocol built on OAuth 2.0, which lets you securely sign in a user from Azure AD to an application. Before going into the sample code, you must first set up an Azure AD tenant and create an application registration with a redirect URL and client secret. The tenant ID, application (client) ID, and client secret are used by Open Liberty to negotiate with Azure AD to complete an OAuth 2.0 authorization code flow.

Learn how to set up Azure AD from these articles:

Configure social media login as OpenID Connect client

The following sample code shows how an application running on an Open Liberty server is configured with the socialLogin-1.0 feature as an OpenID Connect client to authenticate a user from an OpenID Connect Provider, with Azure AD as the designated security provider.

The relevant server configuration in server.xml:

<?xml version="1.0" encoding="UTF-8"?>
<server description="defaultServer">

    <!-- Enable features -->
    <featureManager>
        <feature>cdi-2.0</feature>
        <feature>jaxb-2.2</feature>
        <feature>jpa-2.2</feature>
        <feature>jsf-2.3</feature>
        <feature>jaxrs-2.1</feature>
        <feature>ejbLite-3.2</feature>
        <feature>socialLogin-1.0</feature>
        <feature>transportSecurity-1.0</feature>
        <feature>appSecurity-3.0</feature>
        <feature>jwt-1.0</feature>
        <feature>mpJwt-1.1</feature>
        <feature>mpConfig-1.3</feature>
    </featureManager>

    <!-- trust JDK’s default truststore -->
    <ssl id="defaultSSLConfig"  trustDefaultCerts="true" />

    <oidcLogin
        id="liberty-aad-oidc-javaeecafe" clientId="${client.id}"
        clientSecret="${client.secret}"
        discoveryEndpoint="https://login.microsoftonline.com/${tenant.id}/v2.0/.well-known/openid-configuration"
        signatureAlgorithm="RS256"
        userNameAttribute="preferred_username" />

    <!-- JWT consumer -->
    <mpJwt id="jwtUserConsumer"
        jwksUri="https://login.microsoftonline.com/${tenant.id}/discovery/v2.0/keys"
        issuer="https://login.microsoftonline.com/${tenant.id}/v2.0"
        audiences="${client.id}"
        userNameAttribute="preferred_username"
        authFilterRef="mpJwtAuthFilter" />

    <!-- JWT auth filter -->
    <authFilter id="mpJwtAuthFilter">
        <requestUrl id="myRequestUrl" urlPattern="/rest" matchType="contains"/>
    </authFilter>

    <httpEndpoint id="defaultHttpEndpoint" host="*"
        httpPort="9080" httpsPort="9443" />

    <!-- Automatically expand WAR files and EAR files -->
    <applicationManager autoExpand="true" />

    <dataSource id="JavaEECafeDB"
        jdbcDriverRef="postgresql-driver" jndiName="jdbc/JavaEECafeDB"
        transactional="true" type="javax.sql.ConnectionPoolDataSource">
        <properties databaseName="postgres" portNumber="5432"
            serverName="${postgresql.server.name}" user="${postgresql.user}"
            password="${postgresql.password}" />
    </dataSource>

    <jdbcDriver id="postgresql-driver"
        javax.sql.ConnectionPoolDataSource="org.postgresql.ds.PGConnectionPoolDataSource"
        javax.sql.XADataSource="org.postgresql.xa.PGXADataSource"
        libraryRef="postgresql-library" />

    <library id="postgresql-library">
        <fileset dir="${shared.resource.dir}"
            id="PostgreSQLFileset" includes="postgresql-42.2.4.jar" />
    </library>

    <webApplication id="javaee-cafe"
        location="${server.config.dir}/apps/javaee-cafe.war">
        <application-bnd>
            <security-role name="users">
                <special-subject type="ALL_AUTHENTICATED_USERS" />
            </security-role>
        </application-bnd>
    </webApplication>
</server>

(Find this code sample in GitHub.)

The oidcLogin element has a large number of available configuration options in Open Liberty. With Azure AD, most of them are not required and you can use only the few options used in the code example. This is because Azure AD supports discovery endpoints as is shown in the code example. Discovery endpoints allow for most OpenID Connect configuration to be automatically retrieved by the client, significantly simplifying configuration. In addition, Azure AD instances follow a known pattern for discovery endpoint URLs, allowing us to parameterize the URL using a tenant ID. In addition to that, a client ID and secret are needed. RS256 must be used as the signature algorithm with Azure AD.

The userNameAttribute parameter is used to map a token value from Azure AD to a unique subject identity in Liberty. There are a number of Azure AD token values you can use. Do be cautious, as the required tokens that exist for v1.0 and v2.0 differ (with v2.0 not supporting some v1.0 tokens). Either preferred_username or oid can be safely used, although in most cases you will probably want to use the preferred_username.

Using Azure AD allows your application to use a certificate with a root CA signed by Microsoft’s public certificate. This certificate is added to the default cacerts of the JVM. Trusting the JVM default cacerts ensures a successful SSL handshake between the OIDC Client and Azure AD (i.e., setting the defaultSSLConfig trustDefaultCerts value to true).

In our case, we assign all users authenticated via Azure AD the users role. More complex role mappings are possible with Liberty if desired.

Use OpenID Connect to authenticate users

The sample application exposes a JSF client, which defines a Java EE security constraint that only users with the role users can access.

The relevant configuration in web.xml:

<?xml version="1.0" encoding="UTF-8"?>
<web-app version="3.1"
    xmlns="http://xmlns.jcp.org/xml/ns/javaee"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd">
    <context-param>
        <param-name>javax.faces.PROJECT_STAGE</param-name>
        <param-value>Production</param-value>
    </context-param>
    <servlet>
        <servlet-name>Faces Servlet</servlet-name>
        <servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
        <load-on-startup>1</load-on-startup>
    </servlet>
    <servlet-mapping>
        <servlet-name>Faces Servlet</servlet-name>
        <url-pattern>*.xhtml</url-pattern>
    </servlet-mapping>

    <servlet>
        <servlet-name>javax.ws.rs.core.Application</servlet-name>
    </servlet>
    <servlet-mapping>
        <servlet-name>javax.ws.rs.core.Application</servlet-name>
        <url-pattern>/rest/*</url-pattern>
    </servlet-mapping>

    <session-config>
        <session-timeout>
            30
        </session-timeout>
    </session-config>

    <welcome-file-list>
        <welcome-file>index.xhtml</welcome-file>
    </welcome-file-list>

    <security-role>
        <role-name>users</role-name>
    </security-role>

    <security-constraint>
        <web-resource-collection>
            <web-resource-name>javaee-cafe</web-resource-name>
            <url-pattern>/*</url-pattern>
        </web-resource-collection>
        <auth-constraint>
            <role-name>users</role-name>
        </auth-constraint>
    </security-constraint>
</web-app>

(Find this code sample in GitHub.)

Workflow

The following diagram illustrates the OpenID Connect sign-in and token acquisition flow from Microsoft identity platform and OpenID Connect protocol:

This is standard Java EE security. When an unauthenticated user attempts to access the JSF client, they are redirected to Microsoft to provide their Azure AD credentials. Upon success, the browser gets redirected back to the client with an authorization code. The client then contacts Microsoft again with the authorization code, client ID and secret to obtain an ID token and access token, and finally create an authenticated user on the client, which then gets access to the JSF client.

To get authenticated user information, use the @Inject annotation to obtain a reference to the javax.security.enterprise.SecurityContext and call its method getCallerPrincipal():

@Named
@SessionScoped
public class Cafe implements Serializable {

    @Inject
    private transient SecurityContext securityContext;

    public String getLoggedOnUser() {
        return securityContext.getCallerPrincipal().getName();
    }
}

Find this code sample in GitHub.)

Secure internal REST calls using JWT RBAC

The Cafe bean depends on CafeResource, a REST service built with JAX-RS, to create, read, update and delete coffees. The CafeResource service implements RBAC (role-based access control) using MicroProfile JWT to verify the groups claim of the token.

@Path("coffees")
public class CafeResource {

    private static final Logger logger = Logger.getLogger(MethodHandles.lookup().lookupClass().getName());

    @Inject
    private CafeRepository cafeRepository;

    @Inject
    @ConfigProperty(name = "admin.group.id")
    private String ADMIN_GROUP_ID;

    @Inject
    private JsonWebToken jwtPrincipal;

    @DELETE
    @Path("{id}")
    public void deleteCoffee(@PathParam("id") Long coffeeId) {
        if (!this.jwtPrincipal.getGroups().contains(ADMIN_GROUP_ID)) {
            throw new WebApplicationException(Response.Status.FORBIDDEN);
        }

        try {
            this.cafeRepository.removeCoffeeById(coffeeId);
        } catch (IllegalArgumentException ex) {
            logger.log(Level.SEVERE, "Error calling deleteCoffee() for coffeeId {0}: {1}.",
                    new Object[] { coffeeId, ex });
            throw new WebApplicationException(Response.Status.NOT_FOUND);
        }
    }

    @GET
    @Produces({ MediaType.APPLICATION_XML, MediaType.APPLICATION_JSON })
    public List<Coffee> getAllCoffees() {
        return this.cafeRepository.getAllCoffees();
    }

    @POST
    @Consumes({ MediaType.APPLICATION_XML, MediaType.APPLICATION_JSON })
    @Produces({ MediaType.APPLICATION_XML, MediaType.APPLICATION_JSON })
    public Coffee createCoffee(Coffee coffee) {
        try {
            return this.cafeRepository.persistCoffee(coffee);
        } catch (PersistenceException e) {
            logger.log(Level.SEVERE, "Error creating coffee {0}: {1}.", new Object[] { coffee, e });
            throw new WebApplicationException(e, Response.Status.INTERNAL_SERVER_ERROR);
        }
    }
}

(Find this code sample in GitHub.)

The admin.group.id is injected into the application using MicroProfile Config at the application startup using the ConfigProperty annotation. MicroProfile JWT enables you to @Inject the JWT (JSON Web Token). The CafeResource REST endpoint receives the JWT with the preferred_username and groups claims from the ID Token issued by Azure AD in the OpenID Connect authorization workflow. The ID Token can be retrieved using the com.ibm.websphere.security.social.UserProfileManager and com.ibm.websphere.security.social.UserProfile APIs.

Here is the relevant configuration snippet in server.xml:

<?xml version="1.0" encoding="UTF-8"?>
<server description="defaultServer">

    <!-- Enable features -->
    <featureManager>
        <feature>jwt-1.0</feature>
        <feature>mpJwt-1.1</feature>
        <feature>mpConfig-1.3</feature>
    </featureManager>

    <!-- JWT consumer -->
    <mpJwt id="jwtUserConsumer"
        jwksUri="https://login.microsoftonline.com/${tenant.id}/discovery/v2.0/keys"
        issuer="https://login.microsoftonline.com/${tenant.id}/v2.0"
        audiences="${client.id}"
        userNameAttribute="preferred_username"
        authFilterRef="mpJwtAuthFilter" />

    <!-- JWT auth filter -->
    <authFilter id="mpJwtAuthFilter">
        <requestUrl id="myRequestUrl" urlPattern="/rest" matchType="contains"/>
    </authFilter>
</server>

(Find this code sample in GitHub.)

Note, the groups claim is not propagated by default and requires additional Azure AD configuration. To add a groups claim into the ID token, you need to create a group with type as Security and add one or more members to it in Azure AD. In the application registration created as part of Azure AD configuration, you also need to find Token configuration, select Add groups claim, select Security groups as group types to include in ID token, then expand ID and select Group ID in the Customize token properties by type section. Learn more details from these articles:

Summary

In this blog entry, we demonstrated how to effectively secure an Open Liberty application using OpenID Connect and Azure Active Directory. This write-up and the underlying official Azure sample should also easily work for WebSphere Liberty. This effort is part of a broader collaboration between Microsoft and IBM to provide better guidance and tools for developers using Java EE, Jakarta EE (Java EE has been transferred to the Eclipse Foundation as Jakarta EE under vendor-neutral open source governance), and MicroProfile (MicroProfile is a set of open source specifications that build upon Java EE technologies and target the microservices domain) on Azure.

We would like to hear from you as to what kind of tools and guidance you need. If possible, please fill out a five-minute survey on this topic and share your invaluable feedback—especially if you are interested in working closely with us (for free) on a cloud migration case.

Reza Rahman is Principal Program Manager for Java on Azure at Microsoft.

New features for MicroProfile 4.0 and more Jakarta EE 9 features in Open Liberty 20.0.0.10 beta

Wed, 02 Sep 2020 00:00:00 +0000

In this release of Open Liberty Beta you can try the new features for MicroProfile 4.0 which are Fault Tolerance 3.0, Metrics 3.0, Health 3.0 and OpenTracing 2.0 plus more Jakarta EE 9 features.

We have two beta packages for Open Liberty:

All Beta Features: a new, larger package that contains all Open Liberty beta features (including Jakarta EE 9 beta features) and GA features and functions.
Jakarta EE 9 Beta Features: a lightweight package that contains only the Jakarta EE 9 features.

This means that you can now try out our in-development Open Liberty features by just adding the relevant coordinates to your build tools (either the All Beta Features package or the Jakarta EE 9 Beta Features package, depending on what you want to try).

If you try either package, let us know what you think.

All Beta Features package

The All Beta Features package includes the following beta features:

MicroProfile Fault Tolerance 3.0
MicroProfile Metrics 3.0
MicroProfile Health 3.0
MicroProfile OpenTracing 2.0
Jakarta EE 9 Beta Features package

MicroProfile Fault Tolerance 3.0

MicroProfile Fault Tolerance allows you to easily apply strategies for mitigating failure to their code. It provides annotations which you can add to methods to use bulkhead, circuit breaker, retry, timeout and fallback strategies.

Fault Tolerance 3.0 overhauls the metrics that are automatically exported by Fault Tolerance to take advantage of tags and make it easier to use those metrics to understand when and where your application is failing.

Information which was previously included in the metric name is now included as metric tags, making it much easier to query for data from multiple methods and pick out which, if any, is causing issues.

Example:

Old metric: application:ft.<name>.timeout.callsTimedOut.total

New metric: base:ft.timeout.calls.total{method="<name>", timedOut="true"}`

Try it now

Enable Fault Tolerance 3.0 and CDI in the server.xml, along with any other features you’re using.

<featureManager>
  <feature>mpFaultTolerance-3.0</feature>
  <feature>cdi-2.0</feature>
  <feature>jaxrs-2.1</feature>
</featureManager>

Add any of the Fault Tolerance annotations to a business method of a CDI bean.

@Retry(5)
public User lookupUserFromRegistry(String name) {
  return registry.getUser(name);
}

When that method is called as a a CDI business method, the fault tolerance strategy will be used. In this example, if lookupUserFromRegistry() would throw an exception, it will instead be retried up to five times.

Get an introduction to MicroProfile Fault Tolerance with the Open Liberty guides Failing fast and recovering from errors and Preventing repeated failed calls to microservices.

For more information:

MicroProfile Metrics 3.0

MicroProfile Metrics 3.0 (as part of MicroProfile 4.0) introduces new metric values for the existing SimpleTimer and Timer metrics. Additionally a new REST metric is introduced for better monitoring and handling of unmapped exceptions. Manual configuration for re-usability has been removed. A notable change to the MicroProfile Metrics programming model regarding CDI Producers has been made. Lastly a medley of API improvements and refactoring have been added in this release.

SimpleTimer

The SimpleTimer metric now tracks and reports the highest and lowest recorded time duration of the previous complete minute. See SimpleTimer Javadoc for more information.

Timer

The Time metric now tracks and reports the total elapsed time duration. See Timer Javadoc for more information.

REST metric

A new REST.request.unmappedException.total metric that is backed by a counter metric has been introduced. Similar to the REST.request metric, there will be one unique metric for each REST endpoint identified by a class and method label. The new REST metric will count the amount of times the request ends in an unmapped exception. The REST.request metric corresponding to this REST endpoint will not record any values if an unmapped exception has occured.

CDI Producer

The @Metrics annotation will no longer support the method target (i.e it can not be annotated on a method). Additionally, it will not support usage with CDI Producers.

Try it now

Enable Metrics 3.0 in the server.xml, along with any other features you’re using.

<featureManager>
    <feature>mpMetrics-3.0</feature>
</featureManager>

More information:

MicroProfile Health 3.0

MicroProfile Health 3.0 enables you to provide your own health check procedures to be invoked by Open Liberty, to verify the health of your microservice.

MicroProfile Health allows services to report their health, and it publishes the overall health status to a defined endpoint. A service reports UP if it is available and reports DOWN if it is unavailable. MicroProfile Health reports an individual service status at the endpoint and indicates the overall status as UP if all the services are UP. A service orchestrator can then use the health statuses to make decisions.

MicroProfile Health checks its own health by performing necessary self-checks and then reports its overall status by implementing the API provided by MicroProfile Health. A self-check can be a check on anything that the service needs, such as a dependency, a successful connection to an endpoint, a system property, a database connection, or the availability of required resources. MicroProfile offers checks for both liveness and readiness.

In the mpHealth-3.0 feature for Open Liberty:

The overall default Readiness status was changed to DOWN, with an empty response until all the deployed application(s) have been started. A new MicroProfile Config property (mp.health.default.readiness.empty.response=UP) is introduced to change the overall default Readiness check status to UP, during application start up, that do not have any user-defined health checks.
The HealthCheckResponseBuilder.state(Boolean UP) method was also renamed to HealthCheckResponseBuilder.status(Boolean UP) for HealthCheckResponse deserialization compatibility, where the JSON health check response string can now be deserialized into an HealthCheckResponse object.
The deprecated @Health qualifier was removed, and you should use the @Liveness or @Readiness qualifiers in your HealthCheck implementations, as appropriate.

Applications are expected to provide health check procedures by implementing the HealthCheck interface with the @Liveness or @Readiness annotations. These are used by Open Liberty to verify the Liveness or Readiness of the application, respectively. Add the logic of your health check in the call() method, and return the HealthCheckResponse object, by using the simple up()/down() methods from the API:

**Liveness Check**
@Liveness
@ApplicationScoped
public class AppLiveCheck implements HealthCheck {
...
    @Override
     public HealthCheckResponse call() {
       ...
       HealthCheckResponse.up("my-liveness-check");
       ...
     }
}

**Readiness Check**
@Readiness
@ApplicationScoped
public class AppReadyCheck implements HealthCheck {
...
    @Override
     public HealthCheckResponse call() {
       ...
       HealthCheckResponse.named("my-app-readiness").status(isMyAppReady()).build();
       ...
     }
}
...

To view the status of each health check, access the either the http://<hostname>:<port>/health/live or http://<hostname>:<port>/health/ready endpoints.

More information:

MicroProfile OpenTracing 2.0

MicroProfile OpenTracing 2.0 can be used to profile and monitor applications built using microservice architecture.

MicroProfile OpenTracing 2.0 has upgraded the OpenTracing API to version 0.33.0. This allows the use of tracing backends and their libraries that are built on OpenTracing API 0.33.0.

Try it now

Include the following in the server.xml:

    <feature>mpOpenTracing-2.0</feature>

Also configure a tracing backend such as Jaeger or Zipkin.
For Jaeger, add the following maven dependencies in the application’s pom.xml.

<dependency>
    <groupId>io.jaegertracing</groupId>
    <artifactId>jaeger-client</artifactId>
    <version>1.2.0</version>
</dependency>
<dependency>
    <groupId>org.slf4j</groupId>
    <artifactId>slf4j-api</artifactId>
    <version>1.7.30</version>
</dependency>
<dependency>
    <groupId>org.slf4j</groupId>
    <artifactId>slf4j-jdk14</artifactId>
    <version>1.7.30</version>
</dependency>

You can find out more about about configuring Jaeger settings using environment variables by looking at jaeger-client-java readme.

For the JAEGER_PASSWORD environment variable, the password can be encoded using the securityUtility command.

Depending on Jaeger’s sampling settings JAEGER_SAMPLER_TYPE and JAEGER_SAMPLER_PARAM, Jaeger may not report every span created by the applications.

For Zipkin, take a look at the sample project to see how to implement a tracer for Liberty.

Define your application in the server.xml:

<webApplication location="yourapp.war" contextRoot="/yourapp">
    <!-- enable visibility to third party APIs -->
    <classloader apiTypeVisibility="+third-party" />
</webApplication>

Once you have hit some JAX-RS endpoints of your application, you should be able to find spans in the user interface of your tracing backend.

More information:

Try it now

To try out these features, just update your build tools to pull the Open Liberty All Beta Features package instead of the main release. The beta works with Java SE 14, Java SE 11, or Java SE 8.

If you’re using Maven, here are the coordinates:

<dependency>
  <groupId>io.openliberty.beta</groupId>
  <artifactId>openliberty-runtime</artifactId>
  <version>20.0.0.10-beta</version>
  <type>pom</type>
</dependency>

Or for Gradle:

dependencies {
    libertyRuntime group: 'io.openliberty.beta', name: 'openliberty-runtime', version: '[20.0.0.10-beta,)'
}

Or take a look at our Downloads page.

Jakarta EE 9 Beta Features package

The main change visible to developers in the Jakarta EE 9 planned release is the names of packages changing to accomodate the new jakarta.* namespace. In this Open Liberty beta, we have more Jakarta EE 9 features with their name change completed.

This Open Liberty beta introduces the following Jakarta EE 9 features which now possess their all-new Jakarta EE 9 package names:

Jakarta Authentication 2.0 (jaspic-2.0)
Jakarta Authorization 2.0 (jacc-2.0)
Jakarta Persistence 3.0 (includes Eclipselink 3.0-RC1.) (jpa-3.0)

These join the Jakarta EE 9 features in previous Open Liberty betas:

Jakarta XML Binding 3.0 (jaxb-3.0)
Jakarta Managed Beans 2.0 (managedBeans-2.0)
Jakarta Concurrency 2.0 (concurrent-2.0)
Jakarta Enterprise Beans Home 4.0 (ejbHome-4.0)
Jakarta Enterprise Beans Lite 4.0 (ejbLite-4.0)
Jakarta Bean Validation 3.0 (beanValidation-3.0)
Jakarta Contexts and Dependency Injection 3.0 (cdi-3.0)
Jakarta WebSocket 2.0 (websocket-2.0; currently the integration with CDI is not completed)
JDBC 4.2 & 4.3 (jdbc-4.2 & jdbc-4.3)
Jakarta Transactions 2.0 (transaction-2.0)
Jakarta JSON Binding 2.0 (jsonb-2.0)
Jakarta JSON Processing 2.0 (jsonp-2.0)
Jakarta Servlet 5.0 (servlet-5.0)
Jakarta Server Pages 3.0 (jsp-3.0)
Jakarta Expression Language 4.0 (el-4.0)

Try it now

If you’re using Maven, here are the coordinates:

<dependency>
    <groupId>io.openliberty.beta</groupId>
    <artifactId>openliberty-jakartaee9</artifactId>
    <version>20.0.0.10-beta</version>
    <type>zip</type>
</dependency>

Or for Gradle:

dependencies {
    libertyRuntime group: 'io.openliberty.beta', name: 'openliberty-jakartaee9', version: '[20.0.0.10-beta,)'
}

Or take a look at our Downloads page.

  <featureManager>
    <feature>jakartaee-9.0</feature>
  </featureManager>

Or you can add the Web Profile convenience feature to enable all of the Jakarta EE 9 Web Profile beta features at once:

  <featureManager>
    <feature>webProfile-9.0</feature>
  </featureManager>

Your feedback is welcomed

Let us know what you think on our mailing list. If you hit a problem, post a question on StackOverflow. If you hit a bug, please raise an issue.

More Jakarta EE 9 features and gRPC support in Open Liberty 20.0.0.9 beta

Wed, 05 Aug 2020 00:00:00 +0000

We now have two beta packages for Open Liberty:

Jakarta EE 9 Beta Features: a lightweight package that contains only the Jakarta EE 9 features.
All Beta Features: a new, larger package that contains all Open Liberty beta and GA features and functions.

This means that you can now try out our in-development Open Liberty features by just adding the relevant coordinates to your build tools (either the Jakarta EE 9 Beta Features package or the All Beta Features package, depending on what you want to try).

If you try either package, let us know what you think.

Jakarta EE 9 Beta Features package

This Open Liberty beta introduces the following Jakarta EE 9 features which now possess their all-new Jakarta EE 9 package names:

Jakarta XML Binding 3.0 (jaxb-3.0)
Jakarta Managed Beans 2.0 (managedBeans-2.0)
Jakarta Concurrency 2.0 (concurrent-2.0)
Jakarta Enterprise Beans Home 4.0 (ejbHome-4.0)
Jakarta Enterprise Beans Lite 4.0 (ejbLite-4.0)
Jakarta Bean Validation 3.0 (beanValidation-3.0)
Jakarta Contexts and Dependency Injection 3.0 (cdi-3.0)
Jakarta WebSocket 2.0 (websocket-2.0; currently the integration with CDI is not completed)
Jakarta Persistence 3.0 (jpa-3.0)

These join the Jakarta EE 9 features in previous Open Liberty betas:

JDBC 4.2 & 4.3 (jdbc-4.2 & jdbc-4.3)
Jakarta Transactions 2.0 (transaction-2.0)
Jakarta JSON Binding 2.0 (jsonb-2.0)
Jakarta JSON Processing 2.0 (jsonp-2.0)
Jakarta Servlet 5.0 (servlet-5.0)
Jakarta Server Pages 3.0 (jsp-3.0)
Jakarta Expression Language 4.0 (el-4.0)

Try it now

If you’re using Maven, here are the coordinates:

<dependency>
    <groupId>io.openliberty.beta</groupId>
    <artifactId>openliberty-jakartaee9</artifactId>
    <version>20.0.0.9-beta</version>
    <type>zip</type>
</dependency>

Or for Gradle:

dependencies {
    libertyRuntime group: 'io.openliberty.beta', name: 'openliberty-jakartaee9', version: '[20.0.0.9-beta,)'
}

Or take a look at our Downloads page.

Enable the Jakarta EE 9 beta features in your app’s server.xml. You can enable the individual features you want (but remember if you enable the jsp-3.0 feature, the servlet-5.0 and el-4.0 features are automatically enabled for you) or you can just add the Jakarta EE 9 convenience feature to enable all of the Jakarta EE 9 beta features at once:

  <featureManager>
    <feature>jakartaee-9.0</feature>
  </featureManager>

Or you can add the Web Profile convenience feature to enable all of the Jakarta EE 9 Web Profile beta features at once:

  <featureManager>
    <feature>webProfile-9.0</feature>
  </featureManager>

TCK progress

TCKs are the tests that we run to ensure that the implementation of a feature meets the Jakarta EE 9 spec. Every implementation, including Open Liberty, must run the TCKs and pass them before the implementation can be considered "Jakarta EE compatible". We’re running the TCKs for the Jakarta EE 9 specs and fixing any problems as we go so that we can be sure that all the features will pass 100% of the tests by the time we release the Jakarta EE 9 features for real. So far, particularly good progress has been made for the EJB Lite, Concurrency, and WebSocket features in this beta. So things are going well.

All Beta Features package

As well as the Jakarta EE 9 features listed above, the new All Beta Features package contains our new gRPC and gRPC Client features which have been available in our nightly builds for a few weeks but are now easy to install from Maven Central too.

Provide and consume gRPC services from your web applications

gRPC is a high-performance, open source universal RPC framework. gRPC support on Liberty allows developers to both provide and consume gRPC services from your web applications. The introduction of gRPC support in Open Liberty now means you can take advantage of the benefits of gRPC more easily than before. Those benefits include great performance, simple service definitions via Protocol Buffers, cross-platform and language support, and wide industry adoption.

Two features are available in beta: grpc-1.0, which enables gRPC services, and grpcClient-1.0, which enables the use of a gRPC client for outbound calls.

Try out gRPC with the following basic Hello World service (add the grpc-1.0 to the server.xml):

package com.ibm.ws.grpc;

import com.ibm.ws.grpc.beans.GreetingBean;

import io.grpc.examples.helloworld.GreeterGrpc;
import io.grpc.examples.helloworld.HelloReply;
import io.grpc.examples.helloworld.HelloRequest;
import io.grpc.stub.StreamObserver;

public class HelloWorldService extends GreeterGrpc.GreeterImplBase {

    public HelloWorldService(){}

    @Override
    public void sayHello(HelloRequest req, StreamObserver<HelloReply> responseObserver) {
        HelloReply reply = HelloReply.newBuilder().setMessage("Hello " + req.getName()).build();
        responseObserver.onNext(reply);
        responseObserver.onCompleted();
    }
}

For this example, the application must provide the helloworld protof definition along with the protobuf compiler output. No additional libraries need to be provided with the application, and once it’s started the helloworld greeter service will be accessible on the server’s HTTP endpoints.

For a client example, a basic Servlet using gRPC can be defined via grpcClient-1.0 with:

package com.ibm.ws.grpc;

import io.grpc.examples.helloworld.GreeterGrpc;
import io.grpc.examples.helloworld.HelloReply;
import io.grpc.examples.helloworld.HelloRequest;

import io.grpc.ManagedChannel;
import io.grpc.ManagedChannelBuilder;
...
@WebServlet(name = "grpcClient", urlPatterns = { "/grpcClient" }, loadOnStartup = 1)
public class GrpcClientServlet extends HttpServlet {

        ManagedChannel channel;
        private GreeterGrpc.GreeterBlockingStub greetingService;

        private void startService(String address, int port)
        {
            channel = ManagedChannelBuilder.forAddress(address , port).usePlaintext().build();
            greetingService = GreeterGrpc.newBlockingStub(channel);
        }

        private void stopService()
        {
            channel.shutdownNow();
        }

        @Override
        protected void doGet(HttpServletRequest reqest, HttpServletResponse response)
            throws ServletException, IOException
        {

            // set user, address, port params
        }

        @Override
        protected void doPost(HttpServletRequest request, HttpServletResponse response)
            throws ServletException, IOException
        {

        // grab user, address, port params
        startService(address, port);
        HelloRequest person = HelloRequest.newBuilder().setName(user).build();
        HelloReply greeting = greetingService.sayHello(person);

        // send the greeting in a response
        stopService();
        }
    }
}

As with the service example, the application must provide the helloworld protof definition along with the protobuf compiler output. All required gRPC client libraries are provided by grpcClient-1.0.

Try it now

To try out these gRPC features, just update your build tools to pull the Open Liberty All Beta Features package instead of the main release. The beta works with Java SE 14, Java SE 11, or Java SE 8.

If you’re using Maven, here are the coordinates:

<dependency>
  <groupId>io.openliberty.beta</groupId>
  <artifactId>openliberty-runtime</artifactId>
  <version>20.0.0.9-beta</version>
  <type>pom</type>
</dependency>

Or for Gradle:

dependencies {
    libertyRuntime group: 'io.openliberty.beta', name: 'openliberty-runtime', version: '[20.0.0.9-beta,)'
}

Or take a look at our Downloads page.

To enable the new beta features in your app, add them to your server.xml:

  <featureManager>
    <feature>grpc-1.0</feature>
    <feature>grpcClient-1.0</feature>
  </featureManager>

Your feedback is welcomed

Let us know what you think on our mailing list. If you hit a problem, post a question on StackOverflow. If you hit a bug, please raise an issue.

Jakarta EE 9 data source access and transactions in Open Liberty beta

Tue, 07 Jul 2020 00:00:00 +0000

In no time at all, we have a second Open Liberty beta which makes available another four Jakarta EE 9 features (JDBC 4.2 & 4.3, JTA 2.0, JSON-B 2.0, JSON-P 2.0), plus JNDI 1.0. This is in addition to the three features we beta’d in the first Open Liberty beta (Servlet 5.0, JSP 3.0, Expression Language 4.0).

Jakarta EE 9: behind the scenes

As we mentioned in our first beta blog post, the most visible change to developers between Jakarta EE 8 and Jakarta EE 9 is the new namespace: javax.* package names are now jakarta.* throughout the Jakarta EE 9 features. Behind the scenes, however, the Jakarta EE 9 project team have been working hard on changes to support Jakarta EE now and in future.

The list of specifications in Jakarta EE 9 has been modified since Jakarta EE 8. A subset of specifications that was part of Java SE 8 has been moved into Jakarta EE 9 instead. Some Jakarta 8 specifications have been removed from Jakarta EE 9, while other specifications from Jakarta EE 8 have been marked optional in Jakarta EE 9. This is intended to lower the bar of entry to new implementations by removing "stable" or legacy specifications, or at least making them optional so that application servers can be certified as compatible without necessarily supporting them.

If you’re interested in reading the Jakarta EE 9 specifications, there are now specifications, APIs, TCKs, and Compatible Implementations (CIs) for every specification. From the top-level specifications, you can navigate to any of the technologies to view their deliverables for their respective Milestone 1 releases. For example, here are the overall Jakarta EE 9 Platform and Jakarta Context Dependency Injection (CDI) 3.0 specifications.

In terms of progress, Jakarta EE 9 Milestone 1 was a great achievement but there’s still some way to go. The APIs are close to being finalized. Many of the component specifications are brand new from a Jakarta EE perspective so there is still some polishing required yet. All of the TCKs are buildable and executable but the success rate is variable, depending on the specific Jakarta EE technology being exercised. This is expected at this point in the game and will make progress every day. All of the TCK executions are on public Jenkins instances and can be monitored. Or, better yet, they always welcome more community help so, if you’re interested, get involved.

Every specification and associated TCK requires a Compatible Implementation (CI) to show completeness. For the Jakarta EE 9 Milestone 1 deliverable, Eclipse Glassfish 6.0.0-M1 fulfills that role. But, as with Jakarta EE 8, there will be additional CIs for Jakarta EE 9, including Open Liberty.

We will demonstrate our on-going progress implementing Jakarta EE 9 on Open Liberty through our regular beta releases, now every 4 weeks.

Jakarta EE 9 features on Open Liberty

This beta of Open Liberty implements Java Database Connectivity (JDBC) integration with Java Transaction API (JTA), JSON-B 2.0 and JSON-P 2.0, plus JNDI 1.0. JNDI is not part of Jakarta EE 9 but it’s included to enable the use of data sources and transactions within applications. When added to the existing Jakarta EE 9 features, this means it is now possible to configure Servlet 5.0, JDBC 4.3 (on Java 11; JDBC 4.2 on Java 8), and JNDI 1.0 so that you can configure your applications to both access data sources and participate in global transactions.

The JSON-B and JSON-P features will come into their own when we finish JAX-RS in a future beta. So keep an eye on future beta blog posts.

Try it now

If you want to get started with the beta just update your build tools to pull the Open Liberty beta instead of the main release. The beta works with Java SE 11 or Java SE 8.

If you’re using Maven, here are the coordinates:

<dependency>
    <groupId>io.openliberty.beta</groupId>
    <artifactId>openliberty-jakartaee9</artifactId>
    <version>20.0.0.8-beta</version>
    <type>zip</type>
</dependency>

Or for Gradle:

dependencies {
    libertyRuntime group: 'io.openliberty.beta', name: 'openliberty-jakartaee9', version: '[20.0.0.8-beta,)'
}

Or take a look at our Downloads page.

To enable the new beta features in your app, add one or more of them to your server.xml (if you enable the jsp-3.0 feature, the servlet-5.0 and el-4.0 features are automatically enabled so you don’t need to explicitly list all three in that case):

Add the features to the server.xml:

<featureManager>
  <feature>jdbc-4.2</feature>
  <feature>jsonb-2.0</feature>
  <feature>jsonp-2.0</feature>
  <feature>jndi-1.0</feature>
  <feature>jsp-3.0</feature>
  <feature>servlet-5.0</feature>
  <feature>el-4.0</feature>
</featureManager>

Alternatively, you can just enable the Jakarta EE 9 convenience feature to enable them all at once:

<server>
  <featureManager>
    <feature>jakartaee-9.0</feature>
  </featureManager>
</server>

Let us know what you think on our mailing list. If you hit a problem, post a question on StackOverflow. If you hit a bug, please raise an issue.

Jakarta EE beta on Open Liberty

Mon, 22 Jun 2020 00:00:00 +0000

Our first Open Liberty beta (released today) makes available the first three Jakarta EE 9 features that we’ve implemented. We’ll be releasing regular betas and adding more Jakarta EE 9 features as we go.

Open Liberty betas

When we first released the Open Liberty open source project, we focused mainly on adding production-quality capabilities to Liberty and releasing completed features. While we have often talked about our in-development work so that you know what’s coming, the only way to get hold of this unfinished code to it try out was to take a look at our nightly builds. This is never ideal because nightly builds can be somewhat unstable, so we wanted to release a regular Open Liberty beta.

Open Liberty betas will contain everything in the most recent Open Liberty release plus features that are not yet finished. While these features are not yet suitable for use in production, we want to get feedback from our user community and make them available to developers to use ahead of a production release. Of course, something appearing in a beta isn’t a guarantee that it’ll end up released: the feedback might be that it is a horrible, terrible, no good, very bad idea, and should be constrained to the dumpster of git history. At the very least, it might change a bit.

Betas and releases every four weeks

We intend to release a new beta every four weeks at the same time as our normal four-weekly Open Liberty release. Usually, the beta (which previews the next release) will be available on the same day as the normal Open Liberty release. So the second beta, 20.0.0.8-beta, will be released on the same day as the 20.0.0.7 Open Liberty release. Today’s beta (which previews the 20.0.0.7 release) is versioned as 20.0.0.7-beta.

This first beta is out of cycle because we wanted it to align with the Jakarta EE 9 Milestone 1 to showcase our Jakarta EE 9 work. So far, Open Liberty has implementations of the servlet-5.0, jsp-3.0, and el-4.0 features, which are all part of the Jakarta EE 9 specification. We will be adding to this list in future betas as we work towards complying with Jakarta EE 9 specification. We are running the TCKs as we go.

Jakarta EE 9 changes

So, what changed between Jakarta EE 8 and Jakarta EE 9? As a developer, the main change you’ll notice is that all the javax package names have been updated to jakarta (other Jakarta EE 9 changes are behind-the-scenes and don’t much affect how you use it). In line with Liberty’s zero migration policy, we will release new versions of all the relevant features so that your existing applications will continue to work unchanged with the feature versions they are currently using.

If you want to switch to running with the Jakarta EE 9 features, you can either recode to make use of the Jakarta EE 9 APIs, or you can use the Eclipse Transformer to bytecode-rewrite Jakarta EE 8 references to Jakarta EE 9. We have been using this tool on Liberty to provide the new Jakarta EE 9 features and it has so far been very successful.

Try it now

If you want to get started with the beta just update your build tools to pull the Open Liberty beta instead of the main release. The beta works with Java SE 11 or Java SE 8.

If you’re using Maven, here are the coordinates:

<dependency>
    <groupId>io.openliberty.beta</groupId>
    <artifactId>openliberty-jakartaee9</artifactId>
    <version>20.0.0.7-beta</version>
    <type>zip</type>
</dependency>

Or for Gradle:

dependencies {
    libertyRuntime group: 'io.openliberty.beta', name: 'openliberty-jakartaee9', version: '[20.0.0.7-beta,)'
}

Or take a look at our Downloads page.

To enable the new beta features in your app, add one or more of them to your server.xml (if you enable the jsp-3.0 feature, the other two are automatically enabled so you don’t need to explicitly list all three in that case):

<featureManager>
  <feature>jsp-3.0</feature>
  <feature>servlet-5.0</feature>
  <feature>el-4.0</feature>
</featureManager>

Let us know what you think on our mailing list. If you hit a problem, post a question on StackOverflow. If you hit a bug, please raise an issue.

Kevin is a co-Release Lead for the Jakarta EE 9 project, working with the wider community to help ensure that a cohesive specification is delivered and represents the expectations of the Jakarta EE Working Group. He works with Alasdair, who is Chief Architect of the Open Liberty project and helps direct the Jakarta EE implementation on Open Liberty. They both work with Laura, who is Content Strategist for Open Liberty and Editor of this blog.

Jakarta EE 8 CRUD API Tutorial using Java 11

Wed, 04 Mar 2020 00:00:00 +0000

Modernizing Java EE apps to cloud-native with MicroProfile, Jakarta EE, and Open Liberty

Thu, 16 Jan 2020 00:00:00 +0000

Michael is Team lead for Cloud native and Senior Consultant at ARS Computer & Consulting

This post is about the technical possibilities provided by Open Liberty and why I’m very confident that you can go very smoothly from a Java EE application to a cloud-native one. I won’t be talking about splitting monoliths into microservices, domain-driven design, or event storming. I’m a senior consultant for cloud-native topics and have worked on Java EE applications with servers like IBM’s WebSphere Application Server (WAS) or Red Hat’s JBoss EAP. I advise companies to move to cloud technologies and to pick the right tools for their environment.

I recently had the task of modernizing an application. It was a Java EE 6 app running on WAS v8. The app itself is a kind of dispatcher. It has a SOAP endpoint to receive standardized XML-messages which it forwards to the desired service. One day, a second version of the XML standard was added. At this point it was easier to split the app in multiple services. At the front were two services (one for each version), which parsed the message. The core service made some transformations and distributed the message to the business services.

As a first step it is always a good idea to get rid of cumbersome traditional application servers. They are stable, high performance environments, but they need a lot of time to start and are hard to configure. If you are using traditional WAS you should move to Open Liberty (or WebSphere Liberty, which is built on Open Liberty). With some limitations (e.g. remote EJBs) it should be possible to easily run your app on Liberty without major adjustments. In fact, some of our clients are still using WAS. As developers, we use Liberty to build our apps locally, while in other environments, we use the client’s setup.

Liberty enables you to add features from Java EE or Jakarta EE alongside features from MicroProfile. The image shows the MicroProfile features:

Blue blocks are good known features from Java EE.
Green blocks are the ones we used in our migrated microservices. I will be discuss in this post why they are useful.
White blocks are other MicroProfile features that are worth looking into but weren’t used in this app.

Resiliency in microservices with MicroProfile and Open Liberty

When you create microservices those microservices communicate with each other. Sometimes you have to use synchronous RESTful calls (as we did from the standard services to the core service). In this situation you should use resilience in your microservices. If you don’t, a broken application can break every app in your calling chain, especially when the response times are long. With MicroProfile you can add resilience to your infrastructure, including defining timeouts in your REST client and using circuitbreaker architectures by just adding annotations to your app code.

If you disagree and say that resilience is the responsibility of a service mesh, you’re right, but you might not yet a service mesh installed in your infrastructure. When you do install a service mesh, I’ve got good news yor you: Open Liberty and MicroProfile integrate well with Istio and recognize the configurations from the mesh. If there are configurations on both the app and the service mesh the service mesh overrules the app. But the service mesh cannot provide fallback resilience. This is because you need business logic to react to errors with solutions (fallbacks) such as caching, returning default values, throwing errors with descriptive error messages, and so on.

Building 12-factor apps with MicroProfile and Open Liberty

If you want to develop a cloud-native application, it is a good idea to look into the 12 factors app paradigm, which provides guidlines on how to build a "Software as a Service" application. Emily provides a good overview. It is important that you prepare your application for cloud platforms and their requirements. I consider "lift-and-shift" to be an anti-pattern. Lift-and-shift just means that you run your application on a different virtual machine, but it’s hard - if not impossible - to benefit from the advantages of elastic scaling, self-healing, or zero-downtime deployments. A better approach would be using the strangler pattern, in which you create a new system around the old system, gradually letting the new system grow over a few years until the old system is "strangled".

Providing observability with MicroProfile Metrics in Open Liberty

MicroProfile provides you with features that you really should look into when developing cloud-native apps. Features like MicroProfile Metrics. When you have multiple, maybe hundreds or thousands of apps running simultaneously, you have to monitor them. Metrics help you out. The applications provide monitoring systems like Prometheus (and Grafana for the UI) with information that you can analyse and add alerts to it. You can probably get metrics like RAM or CPU usage, or the number of restarts, from the cloud platform (e.g. Kubernetes does this). Furthermore, you can create business-driven metrics like "how many orders are placed in my shop" or "how many logins are made in this time" and so on. Be creative! You get new possibilities with this feature. In our case, we added metrics to know which standard version was called with which metadata. That helped us with migrating the clients and business services to the new version.

Tracing microservices with MicroProfile OpenTracing and Open Liberty

Another important topic is tracing. When you create a microservice infrastructure, you end up managing services that communicate synchronously and asynchronously. Either way it is important to be able to follow the path of communication, especially when diagnosing bugs. Imagine you have to find the bug in a calling chain containing 10 apps. Maybe the 10 apps are implemented by different teams. This is very hard with no further support. You can handle this by passing a trace ID to the message and sending this informations to services like Jaeger or Zipkin. MicroProfile supports you with a MicroProfile OpenTracing implementation. Ideally, you trace the whole way. In our case, we trace not only the call from the standard service to the core service, but also at least from the client calling the standard service to the services called by the core service.

Checking the health of microservices with MicroProfile Health Check and Open Liberty

Last, but not least, PaaS cloud platforms like Kubernetes offer self-healing. Kubernetes checks for "liveness" and, if your application is in an unstable state, reboots the app for you. Kubernetes also checks for "readiness" before adding your app to the load balancer so that it can receive traffic. However, Kubernetes defines a pod as ready to receive work when the container is started - not when the server with the app is started and ready. This is very important: imagine scaling your app so that a new instance is created and started. If Kubernetes doesn’t check the readiness of the app itself, though, the first requests will fail because the server and the app aren’t started already. You can help Kubernetes by giving it endpoints in your app to provide information about your app’s readiness.

Convert your Java EE apps to cloud-native apps on Open Liberty

Overall, Open Liberty is a good choice to stepwise conversion of your Java EE applications to the cloud-native paradigm. You can add one feature at a time while you refactor your app to comply with the 12 factors and get rid of older technologies like remote EJBs.

Migrating our apps to microservices on Open Liberty

Tue, 17 Dec 2019 00:00:00 +0000

Igor is Director Framework & Integration at Suva

Our journey starts

A year ago we started to migrate our aging applications from a central Java EE platform to a new OpenShift platform. The goals were to promote the autonomy of the development team, to isolate the applications from each other, and to improve our development process as a whole.

We checked several MicroProfile app servers and soon concluded with certainty that Open Liberty has an active and well-structured community, a production-ready product, and also supports our desire for agile work according to SAFe with monthly release cycles.

Our plan was to migrate four existing applications using the appropriate tools to efficiently develop and meet the requirements for productive use. However, we could not start on a greenfield site but had to consider and integrate into the existing landscape.

Our principles during this journey were to design first using OpenAPI v3 and to reuse as much as possible of existing frameworks and platforms as long as it makes sense in a microservice world. Whereever possible, we aimed to use standards, best practices, and a straightforward implementation strategy without compromising well-known enterprise architectural rules (e.g. TOGAF).

Application 1: Using other microservices

Our first application to migrate was a service to check if an employee is still employed by us in order to allow him to buy train ticket in the name of our company. This application provides two web services according to the interface description of our external partner. This was actually the contract of the service which we did not want to break, so we had to use web service technology for providing the service to our partner. It was a good use case to provide web services. Creating web services is very easy using Open Liberty: just add the jaxws-2.2 feature within the server.xml configuration. The implementation of the web services in turn uses microservices of another application that provides organizational and employee data (Application 2). Great use case for using Microprofile Rest Client as an easy and type-safe approach to invoke other microservices.

Application 2: Using persistence

This second application provides organization and employee data. Actually it was one of the oldest applications, going back almost 30 years. It started as Cobol, later on mixed with Java Business Interfaces. We then added some web services, and finally redesigned the persistence layer using JPA instead of native SQL queries. Last year, we ended up with some new requirements that the underlying data model could not handle well. The app grew and the amount of unused functionality and complexity was far greater than the effort of providing well-designed new services from scratch. So we decided not to migrate this app and, instead, do it all new.

The data storage is in an MSSQL database and Eclipselink/JPA was used for access. The REST interfaces were designed with OpenAPI v3; an OpenAPI generator was used to generate the corresponding Java objects of the interface. Open Liberty provides this functionality with the jpa-2.2, ejblite-3.2, and mpOpenAPI-1.1 features. With this last feature, Open Liberty provides a handy UI for developers exploring the microservice functionality. We were able to reuse logging (Apache Log4j 2) and exception handling from the existing framework.

Application 3: Using existing landscape

The third application provides currency rates for other applications. The use of web services for access to our SAP systems and the currency service supplier was a special feature of this application. This time we did not provide web services; instead we reused existing web services. The data is retrieved in batch mode during the night and made available to other legacy applications. Our company central batch scheduler calls a microservice using a curl command, which then receives a ZIP file containing all the necessary files for further distribution. This last step was already part of the old solution and did not have to be adapted. Finally, because of some security requirements, we used the mpJwt-1.1 and jwt-1.0 features, along with appSecurity-3.0, to get some authentication and authorization functionality out-of-the-box.

Application 4: Using files

The fourth application was all about files: it checked PDF files for PDF/A-2b conformity, converted any formats (such as MS Office documents, emails, and images) to PDF/A-2b format, and assembled several PDF files into one PDF file. JMS queues were used to meet the high speed and throughput requirements as well as the loose coupling principal, allowing parallel execution of incoming requests; this functionality was provided by using the jms-2.0, wasJmsClient-2.0, wasJmsServer-1.0, and mdb-3.2 features.

The interface was designed with OpenAPI v3. This time we used multipart/form-data encoding for the documents transfer. We have reached the limits of the JAX-RS standards that we used. Since the use of multipart/form-data is not yet standardized, the necessary Java objects could not simply be generated with the OpenAPI generator for use by Open Liberty. The JAX-RS community is working on extending the standard to support multipart/form-data. Once this is done, the OpenAPI generator can be adapted accordingly and, hopefully, it will be possible to use a standardized interface. Today, we have to use the IMultipartBody interface in Open Liberty.

Overall experience so far

During our implementation and testing efforts we noticed the outdated version of OpenAPI UI (aka Swagger UI) provided by Open Liberty. There are newer versions to support the use of multipart/form-data and the upload of files. This would allow us to give the developers a tool to access the respective microservices to get familiar with the interface using the "Try it out" feature. Reporting this as an issue to the community we got attention and this should be fixed soon.

In addition to the actual migration of the applications, we have built a CI/CD pipeline that allows us to deploy our microservices to an existing OpenShift Container Platform easily and efficiently. Each application consists of an Open Liberty server in a Docker container. Depending on scalability and reliability considerations, one or more pods are started at runtime. The time needed to start a pod in our environment depends how many cores of CPU are defined to a pod. At the moment we manage to start a pod within 10 seconds, quick enough for our use cases. This is thanks to the low memory footprint, the internal parallelized tasks and reduction of path length of Open Liberty.

With the use of MicroProfile Health and MicroProfile Metrics, we get tools that enable us as a team to take over the operational responsibility for our web services. Our experience so far shows that Open Liberty is very stable and easy to use as long as you have Java EE experience. Our applications run for weeks without restarts; previously we had to restart our central Java EE platform weekly. Open Liberty is absolutely production ready.

With our decision to use Open Liberty we did very well. I am confident that we can achieve our goal of migrating the remaining applications that we are responsible for within the coming year.

Open Liberty is Jakarta EE 8 compatible

Tue, 10 Sep 2019 00:00:00 +0000

Today is a big day in the enterprise Java world. Two years ago, Oracle announced their intention to move Java EE to the Eclipse Foundation, which led to the creation of Jakarta EE. The goal was to move Java EE to a community-driven open source model for future enhancements. The dream is that doing this will enable Jakarta EE to evolve faster, allow more frequent releases, and address the needs of modern applications. The process of moving Java EE to Eclipse was not trivial, it was not simple, but it is finally complete with the release of Jakarta EE 8.

As momentous as this news is, this blog post is not about the release of Jakarta EE. This post is about the implications for Open Liberty. The eagle-eyed among you may have noticed in the past that Open Liberty was not Java EE-certified. This made us very sad, but we didn’t have a license for the Java EE TCK that would let us run them. That is not the case with Jakarta EE though.

Thanks to the heroic efforts of Zech Hein, Scott Highbarger, Hank Ibell, Atosa Khoddamhazrati, Kevin Smith, Nichole Stewart, Gene Thoman, Martin Holder, Dave Waddling, and Chris Webster, I can announce that Open Liberty 19.0.0.6 has passed the Jakarta EE 8 TCK and the Jakarta EE Spec Committee has approved our Compatibility Request. This means that I can put this big shiny sailing ship logo down below and proudly say that Open Liberty is a Jakarta EE-compatible implementation:

For those who have run the compatibility tests, you’ll know how much work is involved in getting here. For those who have not, rest assured that the Open Liberty team are committed to implementing and being compatible with the Jakarta EE and Eclipse MicroProfile programming models. If you’re really interested, here’s the Open Liberty 19.0.0.6 Jakarta EE Platform 8 Certification Summary.

To find out more about Open Liberty, take a look at our Open Liberty guides on Jakarta EE technologies.

Thanks and good night!

Updates:

2019-09-10: Updated list of contributors; updated link to filtered guides list.
2019-09-11: Add link to TCK results.

Jakarta EE and the great naming debate

Wed, 08 May 2019 00:00:00 +0000

At JavaOne 2017 Oracle announced that they would start the difficult process of moving Java EE to the Eclipse Software Foundation. This has been a massive effort on behalf of Eclipse, Oracle and many others and we are getting close to having a specification process and a Jakarta EE 8 platform. We are looking forward to being able to certify Open Liberty to it soon. While that is excellent news, on Friday last week Mike Milinkovich from Eclipse informed the community that Eclipse and Oracle could not come to an agreement that would allow Jakarta EE to evolve using the existing javax package prefix. This has caused a flurry of discussion on Twitter, from panic, confusion, and in some cases outright FUD.

To say that everyone is disappointed with this outcome would be a massive understatement of how people feel. Yes this is disappointing, but this is not the end of the world. First of all, despite what some people are implying, Java EE applications are not suddenly broken today, when they were working a week ago. Similarly, your Spring apps are not going to be broken (yes, the Spring Framework has 2545 Java EE imports, let alone all the upstream dependencies). It just means that we will have a constraint on how Jakarta EE evolves to add new function.

We have got a lot of experience with managing migration in the Open Liberty team. We have a zero migration promise for Open Liberty which is why we are the only application server that supports Java EE 7 and 8 in the same release stream. This means that if you are on Open Liberty, your existing applications are totally shielded from any class name changes in Jakarta EE 9. We do this through our versioned feature which provide the exact API and runtime required by the specification as it was originally defined. We are optimistic about for the future because we have been doing this with Liberty since it was created in 2012.

The question for the community is "how we should move forward from here?" It seems that many in the Jakarta EE spec group at Eclipse are leaning towards quickly renaming everything in a Jakarta EE 9 release. There are advantages and disadvantages to this approach, but it appears favoured by David Blevins, Ian Robinson, Kevin Sutter, Steve Millidge. While I can see the value of just doing a rename now (after all, it is better pull a band aid off fast than slow), I think it would be a mistake if at the same time we do not invest in making the migration from Java EE package names to Jakarta EE package names cost nothing. Something in Liberty we call "zero migration".

Jakarta EE will only succeed if developers have a seamless transition from Java EE to Jakarta EE. I think there are four aspects to pulling off zero migration with a rename:

Existing application binaries need to continue to work without change.
Existing application source needs to continue to work without change.
Tools must be provided to quickly and easily change the import statements for Java source.
Applications that are making use of the new APIs must be able to call binaries that have not been updated.

The first two are trivial to do: Java class files have a constant pool that contains all the referenced class and method references. Updating the constant pool when the class is loaded will be technically easy, cheap at runtime, and safe. We are literally talking about changing javax.servlet to jakarta.servlet, no method changes.

The third one is also relatively simple; as long as class names do not change switching import statements from javax.servlet.* to jakarta.servlet.* is easy to automate.

The last one is the most difficult because you have existing binaries using the javax.servlet package and new source using the jakarta.servlet package. Normally this would produce a compilation error because you cannot pass a jakarta.servlet class somewhere that takes a javax.servlet class. In theory we could reuse the approach used to support existing apps and apply it at compile time to the downstream dependencies, but this will depend on the build tools being able to support this behaviour. You could add something to the Maven build to run prior to compilation to make sure this works, but that might be too much work for some users to contemplate, and perhaps is not close enough to zero migration.

I think if the Jakarta EE community pulls together to deliver this kind of zero migration approach prior to making any break, the future will be bright for Jakarta EE. The discussion has already started on the jakarta-platform-dev mail list kicked off by David Blevins. If you are not a member you can join now on eclipse.org. I am also happy to hear your thought via twitter.

What's next for MicroProfile and Jakarta EE?

Thu, 16 Aug 2018 14:45:00 +0000

This is one of the most common questions I get on forums, conferences---even internally at IBM. Eclipse MicroProfile is fairly well-established with several key features and releases under its belt and the future of Java EE is now being established with Eclipse Jakarta EE. When will these two forces combine? This is a difficult question. Hopefully this post will help explain the circumstances that must occur for this integration.

MicroProfile

First, a brief history of the Eclipse MicroProfile project. MicroProfile was created to extend the Enterprise Java environment for developing microservices. We first selected the minimal three Java EE technologies that would provide a solid base for microservices development – CDI, JAX-RS, and JSON-P. Since that initial release, we have added several other component features to further define the microservices programming model. Our latest MicroProfile release has also included support for Java EE 8.

Each component release of MicroProfile is required to create a specification, an API, and a TCK (Test Compatibility Kit). We also require at least one "compatible implementation"---an open-source implementation that successfully implements the specification, uses the API, and passes the TCK. Periodically, these component features are collected into a higher-level, convenience release known as MicroProfile. At this point in time, the MicroProfile "platform" releases do not define additional specifications, APIs, or TCKs.

Jakarta EE

Let’s talk a bit about the Eclipse Jakarta EE project and its current state of affairs. As stated previously, Jakarta EE is the new home for the Java EE platform. Oracle will continue to own everything associated with Java EE, up to and including Java EE 8. All future development of this Enterprise Java environment after Java EE 8 will be done at Eclipse under the guidance of the Jakarta EE working group. Fantastic progress is being made transferring the Java EE code base to Eclipse under the EE4J top-level project.

Some explanation for naming fans: Jakarta EE is the working group name at Eclipse, while EE4J is the top-level project name for code and materials developed at Eclipse for Jakarta EE. Many times, these two terms could be used synonymously but the brand name we use is Jakarta EE and code in the EE4J projects provide APIs, docs and implementations. It’s intended that there will be multiple independent implementations of Jakarta EE across a variety of open source organizations and projects so the code projects at Eclipse are gathered under a project name, ee4j, that is distinct from the brand name (Jakarta EE).

A couple of things to note with this graphic…

The large number of participating Strategic and Participating Members at the Eclipse Foundation. No longer will the future of Enterprise Java lie with a single entity. But, at the same time, notice that Oracle is very much participating in this consortium.
The progress we are making at transferring the source projects from Oracle to Eclipse. The end goal (100%) is when a component completes a release using the Eclipse processes.

Beyond the transferring of the code itself, Jakarta EE also needs the Java EE Specifications and TCKs. Java EE (along with the JCP) defined standards for Enterprise Java. In order to develop and maintain these standards, Eclipse must be able to define an appropriate specification process. This effort is owned by the Jakarta EE Specification Committee. An initial draft of the specification process has been distributed for review.

At the same time, the compatibility process needs to be defined in order to protect the Jakarta EE brand. There needs to be some expectations and rules put in place so that only "approved" implementations can proudly display the Jakarta EE logo on their product and web pages. This approval process is tightly coupled with the specification process and is also owned by the Jakarta EE Specification Committee.

What’s next?

Both of these Eclipse projects have merit and are making progress in their respective domains, with MicroProfile technologies building upon those being contributed to Jakarta EE. But are the projects themselves ready to be merged? IMHO, no. MicroProfile has grown tremendously from its humble beginnings. We have several new component features and versions that extend the Enterprise Java programming model for microservices development. And we have done this in a relatively short amount of time: Six major MicroProfile releases with sixteen component releases in less than two years.

Due to the enormity and complexities of this move, Jakarta EE is not yet ready to match this rate of progress. And, as Jakarta EE has not yet completed the definition of its specification process, it is not yet ready to accept the fast-paced release cycle required by MicroProfile. The big difference here is that MicroProfile has never tried to be a standards body. MicroProfile produces industry-accepted specifications, not standards. Jakarta EE is trying to replace the JCP Standards body with a more modern, open, and lightweight implementation-first process.

Until Jakarta EE has demonstrated a specification process that allows the rapid, innovative aspects of the MicroProfile project, MicroProfile will maintain its own project dynamics distinct from the EE4J projects. MicroProfile can continue to iterate quickly in parallel to working with the Jakarta EE platform to adopt completed MicroProfile technologies into the next release of Jakarta EE. Over time, the need for this distinction is likely to reduce, especially as many of the same teams and people are involved with both projects. Yours truly is one of the project leads for the MicroProfile project. I also participate on the EE4J PMC as well as the Jakarta EE Steering and Specification Committees. We are working together to make this happen.

Baby steps

In the meantime, there are a few activities that are demonstrating the coming together of these two projects and technologies…

The JAX-RS project under EE4J is actively investigating the possibility of incorporating the MicroProfile Rest Client effort in an upcoming release. This is actually the way we wanted and expected the MicroProfile technologies to grow. We would first rapidly innovate in the MicroProfile arena and, when it was ready, attempt to incorporate the features into the next iteration of the Enterprise Java offering.
In a similar vein, the MicroProfile Config component is actively working on a Java EE Configuration API JSR. This effort was kicked off before Oracle announced the decision to move Java EE to the Eclipse Foundation. A couple of early drafts of their specification have been made available for review. Depending on the success and timing of finalizing the Jakarta EE specification process, maybe this Configuration API JSR would migrate to this new process.
The reactive programming model effort will eventually target Jakarta EE. The team from Lightbend was looking for the best way to incorporate some of their reactive programming ideas into the Enterprise Java space. They determined that the quickest way to make some immediate progress was to develop a MicroProfile component. But, their end game is to become part of Jakarta EE.

IMHO

In conclusion, I do need to emphasize that this post is my view of where we stand and what needs to be done to better integrate MicroProfile with Jakarta EE. This is not a collective view of the MicroProfile community, although they were made aware of this pending article. I do believe that eventually this merging of MicroProfile and Jakarta EE must and will happen. It’s just a matter of timing.

Kevin is Eclipse MicroProfile co-lead and EE4J PMC member.

Open Liberty

SpringBoot 4.0, preview of Jakarta Data 1.1 and more in 25.0.0.12-beta

SpringBoot 4.0

Early preview of Jakarta Data 1.1

Model Context Protocol Server 1.0 updates

Prerequisites

MCP Session Management

MCP Endpoint Discoverability

Liberty MCP Server API Documentation

Updates to Netty‑based HTTP transport on Open Liberty

Limitations of the Beta release:

HTTP

WebSocket

SIP

ALPN

Bring Your Own AES-256 Key

What’s New?

Why It Matters

How to Enable It

Try it now

We welcome your feedback

Enhanced message validation for XML Web Services in 24.0.0.12-beta

Fine-tuning XML Web Services inbound SOAP message validation

XML schema validation

Global XML schema validation

Targeted XML schema validation

Default validation

Global default validation

Targeted default validation

Ignore unexpected elements

Global configuration

Targeted configuration

Try it now

We welcome your feedback

Rethinking microservices

Simplify your configuration with versionless features in 24.0.0.8

Develop and run your apps using 24.0.0.8

Streamline feature selection with versionless Jakarta EE, Java EE, and MicroProfile features

Use the Audit 2.0 feature to avoid generating unnecessary REST Handler records

New guide: Externalizing environment-specific microservice configuration for CI/CD

Get Open Liberty 24.0.0.8 now

Recognize your cloud-native Java development skills with the Liberty Developer Essentials Badge

Who should apply for this badge?

New developers

Experienced developers:

How can I get this badge?

Hands-on Course

End Exam

The first of many…

Get your Liberty Developer Essentials Badge today!

Simplify your runtime configuration with versionless features in 24.0.0.8-beta

Streamline feature selection with versionless Jakarta EE and MicroProfile features

Known limitations

Keep using third party cookies with CHIPS

Enable the full set of MicroProfile 7.0 beta features with the MicroProfile 7.0 convenience feature

Integrate fault tolerance and OpenTelemetry with MicroProfile Fault Tolerance 4.1

server.xml file configuration

bootstrap.properties file configuration

Example application class

Learn more

Document APIs in OpenAPI 3.1 format and more with MicroProfile OpenAPI 4.0

Learn more

Align your REST client with Jakarta RESTful Web Services with MicroProfile Rest Client 4.0

Learn more

Collect and export HTTP metrics and logs with MicroProfile Telemetry 2.0

HTTP Metrics

Logs

MicroProfile Telemetry 2.0 beta known issues

Bring your own Jakarta Data provider with Jakarta Data API 1.0

Learn more

Bring your own Jakarta Faces implementation with Jakarta Faces Container 4.1

Learn more

Improve asynchronous handling with Jakarta WebSocket 2.2

Learn more

Use Jakarta Persistence with improved type safety and other enhancements with Jakarta Persistence 3.2

Learn more

Try it now

We welcome your feedback

Platforms and related versionless features reference list

MicroProfile