Article

Open Liberty 20.0.0.5 brings updates to EJB persistent timers coordination and failover across members

May 13, 2020
Containers Java Kubernetes Microservices
Tom Jennings
Software Developer and Adocate Intern

In Open Liberty 20.0.0.5, you can now configure failover for Enterprise JavaBeans (EJB) persistent timers, load Java Authentication and Authorization Service (JAAS) classes directly from the resource adapter, format your logs to JSON or dev, and specify which JSON fields to leave out of your logs. In this article, we will discuss each of these features and how to implement them.

View the list of fixed bugs in Open Liberty's GitHub Issues listing.

If you're interested in what's coming soon in Open Liberty, take a look at our current development builds, which include GraphQL with Open Liberty.

Run your apps using 20.0.0.5

If you're using Maven, here are the coordinates for running your apps:

<dependency>
    <groupId>io.openliberty</groupId>
    <artifactId>openliberty-runtime</artifactId>
    <version>20.0.0.5</version>
    <type>zip</type>
</dependency>

Or for Gradle:

dependencies {
    libertyRuntime group: 'io.openliberty', name: 'openliberty-runtime', version: '[20.0.0.5,)'
}

Or if you're using Docker:

FROM open-liberty

You can also take a look at our Downloads page or ask a question on Stack Overflow.

EJB persistent timers coordination and failover across members

With Open Liberty 20.0.0.5, developers can add a configurable attribute to the EJB Persistent Timer feature. The new attribute sets a maximum amount of time allowed for a persistent timer to complete before another server can take over and run the timer instead.

Prior to this feature, coordination of automatic EJB persistent timers across multiple Open Liberty servers was limited to ensuring that only a single instance of a timer was created across all servers by configuring the EJB timer service on each to persist timers to the same database. This setup caused a single timer instance to be created on one of the servers but without the ability to go to another server if the original server stops or crashes. To enable failover, this feature adds a new configurable attribute, missedTaskThreshold, which specifies the maximum amount of time that you want to allow for the execution of a persistent timer to complete before allowing another server to take over and run it instead.

Enable the EJB persistent timers feature—or another feature that implicitly enables it, such as ejb-3.2—and configure it to use a data source. In this example, we configure the feature to use the Java EE or Jakarta EE default data source. This much configuration is required regardless of whether you want to enable failover or not.

To add the feature to the server.xml:

<server>
  <featureManager>
    <feature>ejbPersistentTimer-3.2</feature>
    <feature>jdbc-4.2</feature>
    ... other features
  </featureManager>

  <dataSource id="DefaultDataSource">
    <jdbcDriver libraryRef="OraLib"/>
    <properties.oracle URL="jdbc:oracle:thin:@//localhost:1521/EXAMPLEDB"/>
    <containerAuthData user="dbuser" password="dbpwd"/>
  </dataSource>
  <library id="OraLib">
    <file name="${shared.resource.dir}/jdbc/ojdbc8.jar" />
  </library>

  <!-- The following enables failover for persistent timers -->
  <persistentExecutor id="defaultEJBPersistentTimerExecutor" missedTaskThreshold="5m"/>

  ...
</server>

Load JAAS LoginModules from resource adapters

Open Liberty supports JAAS LoginModules for configuring access to J2EE Connector Architecture (JCA)-managed resources. In general, JAAS LoginModules are packaged as a shared library and configured for Open Liberty. Sometimes a JAAS LoginModule is packaged as part of a JCA ResourceAdapter. In the past, to use these JAAS LoginModules, the classes from the ResourceAdapter had to be extracted and configured as a shared library. With this new feature, the jaasLoginModule can now load the classes directly from the resource adapter, simplifying the configuration. Before, it was necessary to package (or repackage) JAAS custom login modules into a separate shared library to configure Open Liberty to use them.

Enable the AppSecurity and JCA features and configure a resource adapter. Use the classProviderRef attribute on the jaasLoginModule element to reference the id of the resource adapter:

<server>
  <featureManager>
    <feature>appSecurity-2.0</feature>
    <feature>jca-1.7</feature>
    ... other features
  </featureManager>

  <resourceAdapter id="eciResourceAdapter" location="${shared.resource.dir}/cicseci.rar"/>

  <!-- classProviderRef indicates that the login module class is found in the resource adapter -->
  <jaasLoginModule id="identityProp" controlFlag="REQUIRED"
      className="com.ibm.ctg.security.idprop.LoginModule"
      classProviderRef="eciResourceAdapter">
    <options propIdentity="Caller"/>
  </jaasLoginModule>

  <jaasLoginContextEntry id="CTGEntry" loginModuleRef="identityProp" name="CTGEntry"/>

  <connectionFactory id="cf1" jndiName="eis/cf1" jaasLoginContextEntryRef="CTGEntry">
    <properties.eciResourceAdapter ConnectionUrl="tcp://localhost" portNumber="2006" serverName="MYSERVER"/>
  </connectionFactory>

  ...
</server>

The same approach can be used for JAAS custom login modules that are packaged within an application. Set the classProviderRef to point to the id of the application, webApplication, or enterpriseApplication element that contains the login module class. When packaging JAAS custom login modules within an application, include the login module within one of the following places:

  • Within a top-level JAR of the enterprise application.
  • Within a resource adapter module of the enterprise application.
  • Within the web module of the enterprise application.
  • Within an EJB module of the enterprise application.
  • Within a web application.

It should be noted that JAAS custom login modules require the use of a resource reference with container-managed authentication.

You can find out more about Configuring a JAAS custom login module for Liberty.

Open Liberty console logging

Open Liberty console logging now has the ability to format logs with date and timestamps and other relevant information. Users can apply different formats, such as JSON or dev, to the server logs that appear in their console.log file by using the consoleFormat logging attribute in the server logging configuration. The dev format is the default format and shows messages in a basic format, with no timestamp or any other relevant information. It only shows the message log level and the message itself.

For example:

consoleFormat=dev (default)
[AUDIT ] CWWKE0001I: The server server1 has been launched.

This feature introduces a new option called simple for the consoleFormat logging server configuration attribute. This new option configures Open Liberty to output logs in the same simple format used in the message.log file, with date/timestamps and other relevant information, to the console.log file or to the console (console.log/standard-out).

For example:

consoleFormat=simple
[25/11/19 10:02:30:080 EST] 00000001 com.ibm.ws.kernel.launch.internal.FrameworkManager A CWWKE0001I: The server server1 has been launched.

To configure the Liberty logs to output logs in the new simple console format, you just have to set the following logging server configuration in the server.env, bootstrap.properties, or in the server.xml:

server.env

WLP_LOGGING_CONSOLE_FORMAT=simple

bootstrap.properties

com.ibm.ws.logging.console.format=simple

server.xml

WLP_LOGGING_CONSOLE_FORMAT=simple

Omit specified fields from JSON logging output

In Open Liberty, users can format their server logs in JSON format. When logs are in JSON format, users have to specify the sources (message, trace, accessLog, ffdc, audit) they want to send to messages.log or console.log/standard-out.

Users can now specify the JSON fields they want to omit. This feature adds an option for users to omit JSON fields in the JSON logging process. The option to omit JSON field names in Open Liberty is extremely useful, as users might not want certain default fields provided by Open Liberty in their JSON output. Undesired fields add to the size of the records, which wastes network I/O during record transmissions and wastes space in downstream log aggregation tools. Now, users can choose to emit only the fields they need so they can send to downstream log aggregation tools without using more space and I/O than necessary. For example, someone who's running Open Liberty in Docker containers, with a single server in each container, might not want to include the JSON fields that represent the server name and user directory.

This attribute was initially used only for renaming field names. To rename a JSON field name, the format is specified as source:defaultFieldName:newFieldName or defaultFieldName:newFieldName. To omit defaultFieldName, leave newFieldName empty. For example, to omit a field for all sources, use the defaultFieldName: format. To omit a field for a specific source, use the source:defaultFieldName: format, where source is the source you want to specify, such as message, trace, accessLog, ffdc, or audit.

An example of omitting JSON fields by adding the following to bootstrap.properties:
com.ibm.ws.logging.json.field.mappings=trace:ibm_userDir: ,ibm_datetime:.

You can find more information by viewing Logging and Trace in the IBM Knowledge Center or the Open Liberty Logging documentation.

Try Open Liberty 20.0.0.5 in Red Hat Runtimes now

Open Liberty is part of the Red Hat Runtimes offering. If you're a Red Hat Runtimes subscriber, you can try Open Liberty now.

Last updated: May 30, 2022

Comments