Chapter 7. Known Issues

Google Guava versions 11.0 through 24.1 are vulnerable to unbounded memory allocation in the AtomicDoubleArray class (when serialized with Java serialization) and the CompoundOrdering class (when serialized with GWT serialization). An attacker could exploit applications that use Guava and deserialize untrusted data to cause a denial of service — for more details, see CVE-2018-10237.

To avoid this security vulnerability, we recommend that you:

To make it easier to avoid the earlier (vulnerable) versions of Guava, Fuse 7.7 has configured its Maven Bill of Materials (BOM) files for all containers to select Guava 27 by default. This means that if you incorporate a Fuse BOM into your Maven project (by adding a dependency on the BOM to the dependencyManagement section of your POM file) and then specify a dependency on the Guava artifact without specifying an explicit version, the Guava version will default to the version specified in the BOM, which is version 27 for the Fuse 7.7 BOMs.

But there is at least one common use case involving the Apache Karaf (OSGi) container, where it is not possible to avoid using a vulnerable version of Guava: if your OSGi application uses Guava and Swagger together, you are obliged to use Guava 20, because that is the version required by Swagger. Here we explain why this is the case and how to configure your POM file to revert the earlier (vulnerable) Guava 20 library. First, you need to understand the concept of a double OSGi chain.

Double OSGi chain

Bundles in the OSGi runtime are wired together using package constraints (package name + optional version/range) — imports and exports. Each bundle can have multiple imports and usually those imports wire a given bundle with multiple bundles. For example:

BundleA
+-- BundleB
|   +-- BundleCa
+-- BundleCb

Where BundleA depends on BundleB and BundleCb, while BundleB depends on BundleCa. BundleCa and BundleCb should be the same bundle, if the export the same packages, but due to version (range) constraints, BundleB uses (wires to) a different revision/version of BundleC than BundleA.

Rewriting the preceding diagram to reflect what happens when you include dependencies on both Guava and Swagger in an application:

org.jboss.qe.cxf.rs.swagger-deployment
+-- Guava 27
+-- Swagger 1.5
    +-- reflections 0.9.11
        +-- Guava 20

If you try to deploy this bundle configuration, you get the error, org.osgi.framework.BundleException: Uses constraint violation.

Reverting to Guava 20

If your project uses both Guava and Swagger libraries (directly or indirectly), you should configure the maven-bundle-plugin to use an explicit version range (or no range at all) for the Guava bundle import, as follows:

<Import-Package>
    com.google.common.base;version="[20.0,21.0)",
    com.google.common.collect;version="[20.0,21.0)",
    com.google.common.io;version="[20.0,21.0)"
</Import-Package>

This configuration forces your OSGi application to revert to the (vulnerable) Guava 20 library. It is therefore particularly important to avoid deserializing AtomicDoubleArray instances in this case.

If you want to deploy a standalone Fuse application to Amazon Web Services, you should disable the Fuse Console’s proxy servlet by setting the hawtio.disableProxy system property to true. This requirement applies to all supported standalone environments (Spring Boot 1.x and 2.x, Karaf, and Red Hat JBoss Enterprise Application Platform).

Apache Solr is a popular open source search platform that uses the Apache Lucene search engine. If your application uses a combination of Apache Solr with Apache Lucene (for example, when using the Camel Solr component), it could be affected by this security vulnerability. Please consult the linked security advisory for more details of this vulnerability and the mitigation steps to take.

If you have an existing deployment of Fuse 7.7 Online (or Fuse 7.7 on OpenShift) running on OCP 4.5 and you then upgrade your OpenShift cluster to OCP 4.6, you might find that the new operator channels for Fuse 7.7 (fuse-console-7.7.x, fuse-apicurito-7.7.x, and fuse-online-7.7.x) are not visible initially.

To work around this issue, see ENTESB-15232

Fuse Online 7.7 uses fabric8 kubernetes 4.6.1 which is not updated with changes in the OpenShift 4.5 object model. For OpenShift 4.5, to connect to a Kafka broker, you must know the URI (in host:port format) for the Kafka broker.

On OpenShift 4.4, to enable auto-discovery of Kafka brokers see the Enabling auto-discovery of Kafka brokers/AMQ Streams section in Connecting Fuse Online to Applications and Services.

In Fuse 7.7, specifying the JSon Patch as described in step 7 of the procedure Updating specified fields in a resource on a FHIR server does not work, because the value of the JSon Patch is not used by the connector and the error Unable to determine encoding of patch is raised by the integration.

To work around this issue, you can instead open up the settings for JSon Patch in the Data Mapper, as described in step 9.ii, and directly set the values of the fields, op, path, and value in the Data Mapper (see also the screenshots in ENTESB-14237).

Starting in Fuse 7.6, the Postgres version check is performed during a fresh install, although it is only required during an upgrade. This causes spurious error messages in the log, like the following, which can be safely ignored:

{"level":"error","ts":1583164580.847065,"logger":"configuration","msg":"Unable to determine current version of PostgreSQL running in syndesis-db pod","error":"dial tcp: lookup syndesis-db on 10.0.145.81:53: no such host"

In Fuse 7.7.0, the fabric8-maven-plugin is not compatible with OpenShift Container Platform (OCP) 4.6. That is, if you try to build and deploy a Fuse 7.7.0 Maven project by invoking the mvn fabric8:deploy command, the build fails with an error like this:

[ERROR] F8: Failed to execute the build [Unable to build the image using the OpenShift build service]
Exception in thread "OkHttp Dispatcher" java.util.concurrent.RejectedExecutionException: Task java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask@218c5d87 rejected from java.util.concurrent.ScheduledThreadPoolExecutor@15d41eae[Terminated, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 0]

This error will be fixed in Fuse 7.8.0 (see ENTESB-14511).

If you have an existing deployment of Fuse 7.7 on OpenShift (or Fuse 7.7 Online) running on OCP 4.5 and you then upgrade your OpenShift cluster to OCP 4.6, you might find that the new operator channels for Fuse 7.7 (fuse-console-7.7.x, fuse-apicurito-7.7.x, and fuse-online-7.7.x) are not visible initially and only the old operator channel (alpha) is visible. This is caused by known issues in OCP 4.6 (BZ 1891993 and BZ 1891995). To work around this issue, perform the following procedure as a cluster administrator:

In Fuse 7.7.0, if you follow the procedure for creating and deploying an application using the S2I source workflow, the build on OpenShift fails and in the log you can see an error message like the following:

Caused by: org.eclipse.aether.resolution.ArtifactResolutionException: Could not find artifact org.jboss.redhat-fuse:fuse-springboot-bom:pom:7.7.0.fuse-sb2-770010-redhat-00001 in central (https://repo.maven.apache.org/maven2)

To work around this problem, we recommend that you switch to the S2I binary workflow for building the quickstarts (see Creating and deploying an application using the S2I binary workflow).

Alternatively, if you want to stick with the S2I source workflow, you can revert to an earlier version of the relevant container image by setting the parameter, BUILDER_VERSION=1.6 in the oc new-app command. Because this alternative workaround uses an older version of the container images, however, it is not recommended for use in a production environment. For example, to build the spring-boot-camel quickstart for Spring Boot 2 in the S2I source workflow, enter the following command:

oc new-app --template=s2i-fuse77-spring-boot-2-camel -p APP_NAME=spring-boot-camel -p BUILDER_VERSION=1.6

In Fuse 7.7.0, the Fuse Console deployment on OpenShift becomes unstable after a while, continuously stopping and restarting accompanied by the error Liveness probe failed. This instability is caused by the Fuse Console pod exceeding its memory allocation on OpenShift. To fix the instability, modify the memory limits for the Fuse Console deployment as follows:

In Fuse 7.7.0, the README files in the Spring Boot 1 and Spring Boot 2 quickstarts for Fuse on OpenShift contain incorrect instructions for importing and using the Java image. The following command for importing the Java image:

oc import-image fis-java-openshift:2.0 --from=registry.access.redhat.com/jboss-fuse-7/fis-java-openshift:2.0 --confirm

Should be replaced by this command:

oc import-image fuse-java-openshift:1.7 --from=registry.redhat.io/fuse7/fuse-java-openshift:1.7 --confirm

And the following command for running the quickstart using the downloaded image:

mvn clean -DskipTests fabric8:deploy -Popenshift -Dfabric8.generator.fromMode=istag -Dfabric8.generator.from=MY_PROJECT_NAME/fis-java-openshift:2.0

Should be replaced by this command:

mvn clean -DskipTests fabric8:deploy -Popenshift -Dfabric8.generator.fromMode=istag -Dfabric8.generator.from=MY_PROJECT_NAME/fuse-java-openshift:1.7

But neither of the above commands need to be run if you have already pre-installed the Fuse images, as described in the installation instructions from the Fuse on OpenShift Guide.

Starting in Fuse 7.5.0, some of the Spring Boot 2 quickstarts (generated either from Maven archetypes or quickstart templates) fail to build and deploy to OpenShift. The following Spring Boot 2 Maven archetypes are affected:

And the following Spring Boot 2 templates:

To work around this issue, after generating a Maven project for one of these quickstarts, edit the project’s Maven pom.xml file to add the following dependency:

<dependency>
  <groupId>org.assertj</groupId>
  <artifactId>assertj-core</artifactId>
  <version>2.4.1</version>
  <scope>test</scope>
</dependency>

Starting in the Fuse 7.0 GA release, in the Apache Karaf container the start level of hot deployed bundles is 80 by default. This can cause problems for the hot deployed bundles, because there are many system bundles and features that have the same start level. To work around this problem and ensure that hot deployed bundles start reliably, edit the etc/org.apache.felix.fileinstall-deploy.cfg file and change the felix.fileinstall.start.level setting as follows:

felix.fileinstall.start.level = 90

The framework-security OSGi feature must be installed using the --no-auto-refresh option, otherwise this feature will shut down the Apache Karaf container. For example:

feature:install -v --no-auto-refresh framework-security

In Fuse 7.7, there is an error in the README instructions for the new SOAP to Rest quickstart (camel-soap-rest-bridge). In the Prerequisites section, the command for installing the RH SSO EAP Adapter is given as:

./bin/jboss-cli.sh --file=bin/adapter-elytron-install-offline.cli

But the correct command is actually:

./bin/jboss-cli.sh --file=bin/adapter-elytron-install-offline.cli -Dserver.config=standalone-full.xml