Release Notes for Eclipse Vert.x 3.8

Red Hat build of Eclipse Vert.x 3.8

For use with Eclipse Vert.x 3.8.5

Red Hat Customer Content Services

Abstract

This Release Note contains important information related to Eclipse Vert.x 3.8.5

Preface

Date of release: 2020-02-24

Chapter 1. Required Infrastructure Component Versions

Red Hat does not provide support for components listed below, with the exception of components explicitly designated as supported.

Component nameVersion

Maven

3.6.0

Fabric8 Maven Plugin

4.3.1

JDK[a][b]

OpenJDK 8, OpenJDK 11[c]

Red Hat Enterprise Linux 7[d]

7.7

Red Hat Enterprise Linux 8[e]

8.1

OpenShift Container Platform (OCP)[f]

3.11, 4.3

Minishift

1.34.2 or later

CDK[g]

3.11.0

git

2.0 or later

oc command line tool

3.11 or later[h]

[a] A full JDK installation is required, as JRE does not provide tools for compiling Java applications from source.
[b] Red Hat OpenJDK is supported by Red Hat
[c] OpenJDK 9 is not supported by Red Hat.
[d] For deploying RHOAR-based applications on stand-alone RHEL in a production environment.
[e] For deploying RHOAR-based applications on stand-alone RHEL in a production environment.
[f] OCP is supported by Red Hat
[g] CDK is supported by Red Hat
[h] The version of the oc CLI tool should correspond to the version of OCP that you are using.

Chapter 2. Supported Eclipse Vert.x Runtime Component Configurations and Integrations

The following resource defines the supported configurations and integrations of Red Hat products with Eclipse Vert.x:

Chapter 3. Features

3.1. New and Changed features

No new features or functionalities are introduced in this release.

3.2. Deprecated features

3.2.1. New connection handler method

The HttpClientRequest.connectionHandler() method is deprecated and will be removed in a future release. Use HttpClient.connectionHandler() method instead to call connection handlers for client requests in your application. For example, use the following code to work with HttpClient.connectionHandler() method:

client.connectionHandler(conn -> {
	// Connection related code
});

3.2.2. Updates in HTTP Methods for WebSocket

The updates in the HTTP methods for WebSocket are:

  • The usage of the term WebSocket in method names was inconsistent. The method names had incorrect capitalization, for example, WebSocket, instead of WebSocket. The methods that had inconsistent usage of WebSocket in the following classes have been deprecated and will be removed in a future release. Use the new methods that have correct capitalization instead.

    • The following methods in HttpServerOptions class are deprecated.

      Deprecated MethodsNew Methods

      getMaxWebsocketFrameSize()

      getMaxWebSocketFrameSize()

      setMaxWebsocketFrameSize()

      setMaxWebSocketFrameSize()

      getMaxWebsocketMessageSize()

      getMaxWebSocketMessageSize()

      setMaxWebsocketMessageSize()

      setMaxWebSocketMessageSize()

      getPerFrameWebsocketCompressionSupported()

      getPerFrameWebSocketCompressionSupported()

      setPerFrameWebsocketCompressionSupported()

      setPerFrameWebSocketCompressionSupported()

      getPerMessageWebsocketCompressionSupported()

      getPerMessageWebSocketCompressionSupported()

      setPerMessageWebsocketCompressionSupported()

      setPerMessageWebSocketCompressionSupported()

      getWebsocketAllowServerNoContext()

      getWebSocketAllowServerNoContext()

      setWebsocketAllowServerNoContext()

      setWebSocketAllowServerNoContext()

      getWebsocketCompressionLevel()

      getWebSocketCompressionLevel()

      setWebsocketCompressionLevel()

      setWebSocketCompressionLevel()

      getWebsocketPreferredClientNoContext()

      getWebSocketPreferredClientNoContext()

      setWebsocketPreferredClientNoContext()

      setWebSocketPreferredClientNoContext()

      getWebsocketSubProtocols()

      getWebSocketSubProtocols()

      setWebsocketSubProtocols()

      setWebSocketSubProtocols()

      The new methods for WebSocket subprotocols use List<String> data type instead of a comma separated string to store items.

    • The following methods in HttpClientOptions class are deprecated.

      Deprecated MethodsNew Methods

      getTryUsePerMessageWebsocketCompression()

      getTryUsePerMessageWebSocketCompression()

      setTryUsePerMessageWebsocketCompression()

      setTryUsePerMessageWebSocketCompression()

      getTryWebsocketDeflateFrameCompression()

      getTryWebSocketDeflateFrameCompression()

      getWebsocketCompressionAllowClientNoContext()

      getWebSocketCompressionAllowClientNoContext()

      setWebsocketCompressionAllowClientNoContext()

      setWebSocketCompressionAllowClientNoContext()

      getWebsocketCompressionLevel()

      getWebSocketCompressionLevel()

      setWebsocketCompressionLevel()

      setWebSocketCompressionLevel()

      getWebsocketCompressionRequestServerNoContext()

      getWebSocketCompressionRequestServerNoContext()

      setWebsocketCompressionRequestServerNoContext()

      setWebSocketCompressionRequestServerNoContext()

    • The following handler methods in HttpServer class are deprecated.

      Deprecated MethodsNew Methods

      websocketHandler()

      webSocketHandler()

      websocketStream()

      webSocketStream()

  • WebsocketRejectedException is deprecated. The methods will throw the UpgradeRejectedException instead.

3.2.3. Deprecated authentication and authorization classes and methods

The following authentication and authorization classes and methods are deprecated and will be replaced in a future release.

  • Classes:

    • AbstractUser
    • PubSecKeyOptions
    • JDBCAuthOptions
    • JDBCHashStrategy
    • AccessToken
    • KeycloakHelper
    • ShiroAuth
    • AuthProviderInternal
  • Methods:

    • User.isAuthorized()
    • User.clearCache()
    • User.setAuthProvider()
    • Oauth2Auth.introspectToken()
    • Oauth2Auth.getFlowType()
    • Oauth2Auth.loadJWK()
    • Oauth2Auth.rbacHandler()
    • Oauth2ClientOptions.isUseBasicAuthorization()
    • Oauth2ClientOptions.setUseBasicAuthorizationHeader()
    • Oauth2ClientOptions.getScopeSeparator()
    • Oauth2ClientOptions.setScopeSeparator()

3.2.4. Methods to create clients that have no shared data sources

Use the following new methods to create clients that do not have shared data sources with other clients. These methods maintain their own data sources.

Deprecated MethodsNew Methods

MongoClient.WebsocketRejectedExceptioncreateNonShared()

MongoClient.create()

JDBCClient.createNonShared()

wJDBCClient.create()

CassandraClient.createNonShared()

CassandraClient.create()

MailClient.createNonShared()

MailClient.create()

Chapter 4. Release components

4.1. Supported Artifacts introduced in this release

No artifacts have been moved form Technology Preview to fully supported in this release:

4.2. Technology Preview artifacts introduced in this release

No new artifacts are provided as Technology Preview in this release.

Note

For more information about the support scope of Red Hat Technology Preview features, see Technology Preview Features Support Scope.

4.3. Artifacts removed in this release

No artifacts are removed in this release.

4.4. Artifacts deprecated in this release

No artifacts are marked as deprecated in this release.

Chapter 5. Fixed issues

This Eclipse Vert.x release incorporates all bugfixes from community release of versions 3.8.4 and 3.8.5. Issues resolved in the community releases are listed in the Eclipse Vert.x 3.8.4 Community Release Notes and the Eclipse Vert.x 3.8.5 Community Release Notes.

5.1. The starr.version property is no longer indicated as missing in projects that include the vertx-kafka-client artifact

In previous releases of Eclipse Vert.x, when building a project that includes the vertx-kafka-client artifact, Maven generated the following warning, potentially causing the build to fail:

The POM for org.scala-lang:scala-compiler:jar:${starr.version} is missing, no dependency information available

This issue is resolved in the Eclipse Vert.x 3.8.5 release and no longer occurs.

5.2. Vert.x AMQP Client:`AmqpReceiver` logs received messages to standard output as expected

In previous releases of Eclipse Vert.x, a messageHandler attached to an AmqpReceiver instance that was set to print a message received from a Sender instance located on the same address to standard output would fail to print the message to the log despite having received it. The issue resulted from using a deprecated createReceiver method to initialize the AmqpReceiver instance. The deprecated method is removed from the vertx-amqp-client module in the Eclipse Vert.x 3.8.5 release and the issue no longer occurs.

Chapter 6. Known issues

6.1. Connection between a RHEL 8-based database application and a RHEL 7-based MySQL 5.7 database fails due to TLS protocol version mismatch

Description

Attempting to open a TLS-secured connection using OpenSSL between an application container built on a RHEL 8-based OpenJDK builder image and a database container built on a RHEL 7-based MySQL 5.7 container image results in a connection failure due to a javax.net.ssl.SSLHandshakeException at runtime: For more detail, view the issue in JIRA.

...
Caused by: javax.net.ssl.SSLHandshakeException: No appropriate protocol (protocol is disabled or cipher suites are inappropriate)
...

Cause

The issue occurs due to a difference in the latest supported TLS protocol version between RHEL 7 and RHEL 8. The TLS implementation on RHEL 7 supports TLS protocol versions 1.0 (deprecated), 1.1, and 1.2. The TLS implementation on RHEL 8 also supports TLS protocol version 1.3, which is also the default TLS version used in RHEL 8-based builder images. This discrepancy may cause a TLS protocol version mismatch between application components while negotiating a TLS handshake, which in turn causes the connection between the application and database containers to fail.

Workaround

To prevent the issue described above, manually specify a TLS protocol version that is supported on both operating system versions in your database connection string. For example:

jdbc:mysql://testdb-mysql:3306/testdb?enabledTLSProtocols=TLSv1.2

6.2. False Connection reset by peer error messages when calling application endpoint

Making an HTTP request on an endpoint of a Vert.x application using either curl or a Java HTTP client, produces the following error in the logs after each request:

io.vertx.core.net.impl.ConnectionBase
SEVERE: java.io.IOException: Connection reset by peer

This behavior is caused by the interaction of the Netty application framework and the HAProxy load-balancer used by OpenShift. The error occurs due to existing HTTP connections being re-used by HAProxy without closing. Even though the error message is logged, no error condition occurs. HTTP requests are handled correctly and the application responds as expected.

Legal Notice

Copyright © 2020 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.