Chapter 6. Known issues

6.1. Thorntail applications fail to boot due to logging 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: 

ERROR: WFLYCTL0013: Operation ("parallel-extension-add") failed - address: ([])
java.lang.RuntimeException: WFLYCTL0079: Failed initializing module org.jboss.as.logging
        ...
Caused by: java.util.concurrent.ExecutionException: java.lang.IllegalStateException: WFLYLOG0078: The logging subsystem requires the log manager to be org.jboss.logmanager.LogManager.
The subsystem has not be initialized and cannot be used.
To use JBoss Log Manager you must add the system property "java.util.logging.manager" and set it to "org.jboss.logmanager.LogManager"

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:

  • The application uses Java agents, such as the Jolokia agent
  • The JDK itself uses logging

Workaround

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

You can switch off the agents using one of the following ways:

  • To switch off Jolokia agent, you should set the following environment variables:

    • AB_OFF to true
    • AB_JOLOKIA_OFF to true

The following example shows an OpenShift deployment configuration where the environment variables are set. 

apiVersion: apps.openshift.io/v1
kind: DeploymentConfig
metadata:
  ...
spec:
  ...
  template:
    metadata:
      ...
    spec:
      containers:
      - image: ...
        env:
        - name: AB_JOLOKIA_OFF
          value: "true"
        - name: AB_OFF
          value: "true"
        ...
  • You can also use Fabric8 Maven plugin to generate the following YAML files. These files set the environment variables as shown in the following code. 
<plugin>
  <groupId>io.fabric8</groupId>
  <artifactId>fabric8-maven-plugin</artifactId>
  <version>${version.io.fabric8.fabric8-maven-plugin}</version>
  <executions>
    <execution>
      <goals>
        <goal>resource</goal>
        <goal>build</goal>
      </goals>
    </execution>
  </executions>
  <configuration>
    <resources>
      <env>
        <AB_OFF>true</AB_OFF>
        <AB_JOLOKIA_OFF>true</AB_JOLOKIA_OFF>
      </env>
    </resources>
  </configuration>
</plugin>
  • You can explicitly configure JBoss LogManager as the java.util.logging.manager. The following example shows you the configuration: 
java -Xbootclasspath/p:/home/test/.m2/repository/org/jboss/logmanager/jboss-logmanager/2.1.14.Final-redhat-00001/jboss-logmanager-2.1.14.Final-redhat-00001.jar:/home/test/.m2/repository/org/wildfly/common/wildfly-common/1.5.1.Final-redhat-00001/wildfly-common-1.5.1.Final-redhat-00001.jar -Djboss.modules.system.pkgs=org.jboss.logmanager,org.wildfly.common -Djava.util.logging.manager=org.jboss.logmanager.LogManager -jar myapp-thorntail.jar

6.2. Eclipse MicroProfile Fault Tolerance: CDI contexts available in @Timeout methods

Description

If your application contains a @Timeout method that uses a contextual service , such as the @RequestScoped MyService shown in the example below, the contexts are not activated for that service. 

@Inject
private MyService service;

@Timeout
public String doSomething() throws InterruptedException {
    return "Hello " + service.call();
}

The method is not @Asynchronous and should, therefore, be executed on the caller thread, which would make the Context and Dependency Injection (CDI) contexts available. However, the following debug message indicates that the contexts are not available: 

2018-04-03 21:16:35,976 ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /: org.jboss.weld.context.ContextNotActiveException: WELD-001303: No active contexts for scope type javax.enterprise.context.RequestScoped

Cause

This issue is caused by @Timeout methods always being invoked on a separate thread, even if they are not @Asynchronous.

Workaround

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

6.3. Harmless error message in application log: Missing org.glassfish:javax.el-api:3.0.1.b08-redhat-1

Description

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

Failed downloading org/glassfish/javax.el-api/3.0.1.b08-redhat-1/javax.el-api-3.0.1.b08-redhat-1.pom from https://repository.jboss.org/nexus/content/groups/public/. Reason:
org.eclipse.aether.transfer.ArtifactNotFoundException: Could not find artifact org.glassfish:javax.el-api:pom:3.0.1.b08-redhat-1 in jboss-public-repository-group (https://repository.jboss.org/nexus/content/groups/public/)
Failed downloading org/glassfish/javax.el-api/3.0.1.b08-redhat-1/javax.el-api-3.0.1.b08-redhat-1.pom from http://repo.gradle.org/gradle/libs-releases-local/. Reason:
org.eclipse.aether.transfer.ArtifactNotFoundException: Could not find artifact org.glassfish:javax.el-api:pom:3.0.1.b08-redhat-1 in gradle (http://repo.gradle.org/gradle/libs-releases-local)
Failed downloading org/glassfish/javax.el-api/3.0.1.b08-redhat-1/javax.el-api-3.0.1.b08-redhat-1.pom from https://repo.maven.apache.org/maven2/. Reason:
org.eclipse.aether.transfer.ArtifactNotFoundException: Could not find artifact org.glassfish:javax.el-api:pom:3.0.1.b08-redhat-1 in central (https://repo.maven.apache.org/maven2)
Failed downloading org/glassfish/javax.el-api/3.0.1.b08-redhat-1/javax.el-api-3.0.1.b08-redhat-1.pom from http://repo1.maven.org/maven2/. Reason:
org.eclipse.aether.transfer.ArtifactNotFoundException: Could not find artifact org.glassfish:javax.el-api:pom:3.0.1.b08-redhat-1 in central (http://repo1.maven.org/maven2)

The message is harmless and does not impact the functionality of the application.

Cause

The likely cause of this issue is related to the way dependency resolution works in Thorntail. During the dependency resolution phase, Thorntail ignores dependency exclusions, and thus pulls in javax.el-api, despite javax.el-api being excluded in the EAP BOM. Because it is interpreted as a valid dependency, it is indicated as missing due to being absent form the repository, which causes the error messages displayed in the build log.

Workaround

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

6.4. 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.5. Thorntail Arquillian Adapter ignores mvn -s settings.xml

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>