Chapter 6. Known issues

Description

Thorntail is based on WildFly. In Wildfly, the value of the java.util.logging.manager property should always be set to org.jboss.logmanager.LogManager (JBoss LogManager). The JBoss Modules initialize the log manager while booting. However, in some cases, java.util.logging is called before the log manager is set. In such cases, the Thorntail application fails to boot and returns the following error:

Cause

The Thorntail application fails to boot if java.util.logging is initialized too early. Some of the reasons for java.util.logging being initialized too early are:

Workaround

To use Thorntail on OpenShift, it is recommended to switch off Java agents that are available in the Red Hat Java S2I images.

Description

If your application, or any of its dependencies, depends on the Java Expression Language, it will display the following warning message during startup.

Cause

This issue is caused by the dependency resolution mechanism in Thorntail. During the dependency resolution phase, Thorntail ignores dependency exclusions, and thus tries to pull the javax.el-api artifacts. However, javax.el-api is not available in the repository, because it is not required and has been excluded. This results in error messages that are displayed in the build log.

Workaround

At the time of this release, there is no workaround available for this issue.

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.

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:

Description

When attempting to pass additional repositories referenced in the setting.xml file to the Thorntail Arquillian adapter when executing integration tests and unit tests, the settings.xml file is not recognized and the additional repositories are not configured. This issue results in build failure due to missing artifacts, which, in turn, causes the tests to fail.

Workaround

To avoid this issue, manually edit the <configuration> sections under the Maven Surefire and/or Maven Failsafe plugin entries in the pom.xml file of your Maven project, manually specifying the <org.apache.maven.user-settings>${session.request.userSettingsFile.path}</org.apache.maven.user-settings> property to be exported when testing your application. See example for details:

pom.xml

<project>
  ...
  <build>
    <plugins>
      ...
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-failsafe-plugin</artifactId>
        <configuration>
          <org.apache.maven.user-settings>${session.request.userSettingsFile.path}</org.apache.maven.user-settings>
        </configuration>
      </plugin>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-surefire-plugin</artifactId>
        <configuration>
          <systemPropertyVariables>
            <org.apache.maven.user-settings>${session.request.userSettingsFile.path}</org.apache.maven.user-settings>
          </systemPropertyVariables>
        </configuration>
      </plugin>
      ...
    </plugins>
  </build>
  ...
</project>