ICEfaces
  1. ICEfaces
  2. ICE-8843

Javascript Exception is throw under IE and WAS8

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: EE-3.0.0.GA_P01, 3.2
    • Fix Version/s: EE-3.2.0.GA
    • Component/s: Framework, ICE-Components
    • Labels:
      None
    • Environment:
      WebSphere 8 and IE browsers
    • Assignee Priority:
      P1
    • Salesforce Case Reference:

      Description

      The following script error is thrown when running the attached test case in WAS8 and IE browsers:

      SCRIPT5007: Unable to set value of the property 'value': object is null or undefined

      This prevents any interaction with the page and a full refresh is needed to recover. With the same code this error does not show when running in Tomcat with IE.

        Activity

        Hide
        Arran Mccullough added a comment -

        Attaching test case that can be deployed to WAS8.

        Steps:

        • load TestIceFaces/z.jsf in IE
        • Click the switch panel button
        • Select a date from the calendar
        • Click the switch panel button again
        • Error is thrown.
        Show
        Arran Mccullough added a comment - Attaching test case that can be deployed to WAS8. Steps: load TestIceFaces/z.jsf in IE Click the switch panel button Select a date from the calendar Click the switch panel button again Error is thrown.
        Hide
        Deryk Sinotte added a comment - - edited

        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:

        ice.onAfterUpdate...

        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.

        Show
        Deryk Sinotte added a comment - - edited 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: ice.onAfterUpdate... 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.

          People

          • Assignee:
            Deryk Sinotte
            Reporter:
            Arran Mccullough
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: