RequestAttributeMap.getPropertyNames(String) contains attribute names that were removed

• Type: Bug
• Status: Closed
• Priority: Minor
• Resolution: Fixed
• Affects Version/s: liferay-faces-3.0.3-legacy-ga4, liferay-faces-3.0.3-ga4, liferay-faces-3.1.3-ga4
• Fix Version/s: liferay-faces-2.1.4-ga5, liferay-faces-2.2.4-ga5, liferay-faces-3.0.4-legacy-ga5, liferay-faces-3.0.4-ga5, liferay-faces-3.1.4-ga5, liferay-faces-3.2.4-ga5
• Component/s: Liferay Faces Bridge Impl / Demos / Tests
• Labels: None
• Environment: Liferay Portal + Mojarra 2.1.26 (or newer), Mojarra 2.2.3 (or newer)

This problem was revealed by the JSR 329 Portlet Bridge TCK after upgrading to Mojarra 2.1.26 (in the Liferay Faces 3.x branches) and Mojarra 2.2.3 (in the Liferay Faces 4.x branches). Those versions of Mojarra contain a fix for JAVASERVERFACES-2989 that reveals a bug in Liferay Portal that is illustrated by the following code fragment:

renderRequest.setAttribute("foo", "1234");
renderRequest.removeAttribute("foo");
Enumeration<String> attributeNames = renderRequest.getAttributeNames();
while (attributeNames.hasMoreElements()) {
    String attributeName = attributeNames.nextElement();
    if (attributeName.equals("foo")) {
        // ERROR CONDITION
    }
}

This bug exists in Liferay Portal 6.2 and 6.1 and likely older versions as well. Therefore it is necessary to work-around this bug in the bridge.

If the bug is fixed, then the TestPage093 (encodeActionURLWithModeActionTest) TCK test will pass correctly. The test makes sure that managed-beans are discarded due to a portlet mode change in a navigation-rule. After the navigation, the Mojarra com.sun.faces.el.ManagedBeanELResolver is supposed to re-create the "test" managed-bean due to the following EL expression found in MultiRequestTestResultRenderCheck.jsp:

#{test.renderTestResult}