RapidDeploy 5.2.5 may fail to display any page after login

How to recognise it

In $MV_HOME/logs/rapiddeploy-web-app.log every page request records:

ERROR com.midvision.rapiddeploy.web.exception.RdExceptionHandler - Fatal error occured.
java.lang.NoSuchMethodError: 'void com.sun.faces.facelets.tag.faces.ComponentSupport
  .addToDescendantMarkIdCache(jakarta.faces.component.UIComponent,
                              jakarta.faces.component.UIComponent)'

A quick check:

grep -c addToDescendantMarkIdCache $MV_HOME/logs/rapiddeploy-web-app.log

The service state, the open port and the HTTP status of the login page all look normal, so they do not reveal the problem.

Am I affected

The outcome depends on the order in which the file system returns the contents of the application's library directory. That order is a property of the file system, so:

• the result is the same on every start for a given installation;
• the same installation package can succeed on one machine and fail on another. Container file systems (for example Docker) were where it was observed;
• reinstalling or redeploying 5.2.5 does not change the outcome.

  Because a working 5.2.5 installation is working only by luck of the file system layout, we recommend upgrading even where the problem has not appeared.

Cause

The 5.2.5 web application shipped the Jakarta Faces API library alongside the Jakarta Faces implementation, which already contains the same API classes. Two copies of those classes were therefore present, and whichever the server loaded first determined the result. The separate API library's copy calls into the implementation in a way the bundled implementation version does not support, so when it was loaded first, no page could be built.

5.2.6 ships the Faces implementation only, so the API classes are present exactly once.

Resolution

Upgrade to RapidDeploy 5.2.6 or later, following the standard upgrade procedure.

Interim workaround for an installation already deployed

If upgrading immediately is not practical, remove the duplicate library from the deployed application. This survives restarts.

Run as the user that owns the RapidDeploy installation:

WEBAPPS=$MV_HOME/web-apps/tomcat/webapps

systemctl stop rapiddeploystart

cp -p $WEBAPPS/MidVision.war $WEBAPPS/MidVision.war.bak
zip -q -d $WEBAPPS/MidVision.war 'WEB-INF/lib/jakarta.faces-api-*.jar'
chown --reference=$WEBAPPS/MidVision.war.bak $WEBAPPS/MidVision.war

rm -rf $WEBAPPS/MidVision

systemctl start rapiddeploystart

Then log in again and confirm that pages display.

Notes on the procedure:

• in a container, run the cp, zip, chown and rm steps inside the container, and restart the container instead of using systemctl;
• removing $WEBAPPS/MidVision forces the server to extract the corrected archive on the next start. Deleting the library from the extracted directory alone is not enough: it returns whenever the archive is extracted again;
• the chown step preserves file ownership. The --reference option requires GNU coreutils, as found on Linux; set the owner and group explicitly on other platforms;
• keep MidVision.war.bak. It is the unmodified 5.2.5 archive;
• removing the library is safe because the Faces implementation that remains contains the complete API;
• this is a workaround, not a substitute for the upgrade. Applying a different package later - an upgrade, or a re-install from the 5.2.5 media - will restore the original archive and the problem with it.