After capturing and comparing the network traffic between IE/Tomcat vs IE/WebSphere, I noticed that they were mostly the same except for the update coming back when selecting a date from the popped up calendar. That update contained some extra functionality for the command links - most noticeable for the addition of:
This seemed to be the function that was complaining so I searched our code for where this might be getting rendered out and found a couple of the following snippets in the com.icesoft.faces.component.ext.renderkit.CommandLinkRenderer:
...
if (ImplementationUtil.isMyFaces()) {
str1 = "ice.onAfterUpdate(function() {";
str2 = "});";
}
...
The ImplementationUtil is an older class for checking environmental values like which JSF implementation is in play. However, this has been largely replaced by the core class org.icefaces.util.EnvUtils.
The actual problem is that, with WAS, even though we deploy the Mojarra library and configure WebSphere to use it, the MyFaces library is still available on the classpath. This means you can't simply check for the availability of the class - you also need to test which implementation is active. For EnvUtils, we did this as part of ICE-7835 but the same changes were not applied to the ImplementationUtil class.
I was able to verify that switching to the use of the EnvUtil methods fixed the problem. I was also able to show that the same problem does manifest on Tomcat if you add the MyFaces libraries to the shared library folder of Tomcat (basically mimicking what is happening on WAS).
After inspecting the ImplemenationUtil class I decided it wasn't really needed anymore so I removed it and switched any imports and references to use EnvUtils instead. It makes sense that we use a common environment utility for these types of things.
Attaching test case that can be deployed to WAS8.
Steps: