Chapter 5. Known issues

This section lists known issues with Red Hat build of Quarkus 1.3.

  • If you add the smallrye-reactive-messaging extension, a warning message about ReactiveX appears when you close Quarkus even if you are not using Reactive APIs in your code. For more information, see Red Hat article 4954651.

  • The quarkus-container-image-s2 extension, which is typically used indirectly through the quarkus-openshift extension, treats the Red Hat OpenJ9 images recommended for s390x architecture as if they do not include the run-java.sh script. This affects the generated openshift.yml file.

    If the image uses the run-java.sh script, the container definition only includes several environment variables. It does not include a command that should be executed in the container. Instead, the default S2I run script is used which executes the run-java.sh script.

    If the image does not use the run-java.sh script, the container definition includes the java command that should be executed in the container.

    One difference between these scenarios is that the run-java.sh script changes the current working directory to the directory where the application JAR file is located, typically /deployments. This is important when mounting a ConfigMap with the application.properties configuration file into the container filesystem. With the run-java.sh script, the ConfigMap typically must be mounted into the /deployments/config directory, while with the other images, the ConfigMap must be mounted into the default working directory defined by the image.

    Note

    This issue does not affect all applications that use the Red Hat OpenJ9 images recommended for s390x architecture.

    Cause

    The quarkus-container-image-s2i extension has a list of known images that contain the run-java.sh script. All other images are treated as if they do not contain the run-java.sh script. This issue will be fixed in a future release.

    Workaround

    • If your application is affected by the current working directory issue, you can define the current working directory of the container in the pod definition. This overrides the default working directory defined in the image. If you use the quarkus-openshift extension to generate the openshift.yml file, use the following configuration property: 

      quarkus.openshift.working-dir=/deployments

    • If your application is affected by the current working directory issue specifically when mounting a ConfigMap with the application.properties configuration file, another option is to mount the ConfigMap into a specific directory. If you use the quarkus-openshift extension, use following configuration property, assuming that the default working directory defined by the image is /home/jboss: 

      quarkus.openshift.mounts.<mount name>.path=/home/jboss/config