back to all blogsSee all blog posts

View stack trace separately from messages in logged exceptions and time-based log rollover in Open Liberty 22.0.0.8

image of author
Ryan Storey on Aug 2, 2022
announcements , release , security , jakarta-ee , monitoring ,
Post available in languages:

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 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.

Ask a question on Stack Overflow

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":

Example logs

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

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.