xPaaS Release Notes

Due to this issue, the logging data is not available for the central logging facility. To work around this issue, use the oc exec command to get the contents of the log file.

Cleaning up after a build in JWS STI is not possible, because the Maven command mvn clean fails. This is due to Maven not being able to build the object model during startup.

To work around this issue, add Red Hat and JBoss repositories into the pom.xml file of the application if the application uses dependencies from there.

It is not possible to do correct JNDI lookup for datasources in the current JWS image if an invalid combination of datasource and realm properties is defined. If a datasource is configured in the context.xml file and a realm in the server.xml file, then the server.xml file’s localDataSource property should be set to true.

JPA applications fail to deploy in the EAP OpenShift Enterprise 3.0 image if an underlying database instance that the EAP instance relies on is not available at the start of the deployment. The EAP application tries to contact the database for initialization, but because it is not available, the server starts but the application fails to deploy.

There are no known workarounds available at this stage for this issue.

In the EAP image, an application not using messaging complains about messaging errors related to HornetQ when being scaled.

Since there are no configuration options to disable messaging to work around this issue, simply include the standalone-openshift.xml file within the source of the image and remove or alter the following lines related to messaging:

In a distributed web application deployed on an EAP image, a new container starts serving requests before it joins the cluster.

There are no known workarounds available at this stage for this issue.

In both the EAP and JWS images, when restarting a crashed database instance, the connection pools contain stale connections.

To work around this issue, restart all instances in case of a database failure.

Attempting to run the karaf client in the container to locally SSH to the karaf console fails.

Workaround: Adding both shell and ssh features make the client work. It will log the warning errors in the logs.

These warnings are logged when trying to use the JBoss Fuse bin/client script to connect to the JBoss Fuse micro-container. This is an unusual case, since the container is supposed to contain only bundles and features required for a micro-service, and hence does not need to be managed extensively like a traditional JBoss Fuse install. Any changes made using commands in the remote shell will be temporary and not recorded in the micro-service’s docker image.

The cdi-camel-http quickstart expects the cdi-camel-jetty service to be named qs-cdi-camel-jetty. In the cdi-camel-jetty template however, the service is named s2i-qs-cdi-camel-jetty instead by default. This causes the cdi-camel-http to output this error when both are deployed using the S2I with default values.

Workaround: Set the cdi-camel-jetty SERVICE_NAME template parameter to qs-cdi-camel-jetty.

oc process karaf-camel-rest-sql template fails with the following error: The Service "s2i-qs-karaf-camel-rest-sql" is invalid. SUREFIRE-859: metadata.name: invalid value 's2i-qs-karaf-camel-rest-sql', Details: must be a DNS 952 label (at most 24 characters, matching regex [a-z]([-a-z0-9]*[a-z0-9])?): e.g. "my-name" deploymentconfig "s2i-quickstart-karaf-camel-rest-sql" created

Workaround: Set SERVICE_NAME template parameter to karaf-camel-rest-sql.

The application template for A-MQ deployments uses a suffix for every transport type to distinguish. Hence there should be a configurable parameter for setting the service name as environment parameter A_MQ_SERVICE_NAME.