ICEfaces
  1. ICEfaces
  2. ICE-8161

ice:selectInputDate - ClassCastException thrown when using MyFaces

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: EE-1.8.2.GA_P04
    • Fix Version/s: EE-1.8.2.GA_P05
    • Component/s: ICE-Components
    • Labels:
      None
    • Environment:
      ICEfaces EE 1.8.2 P04, MyFaces 1.1.5
    • Assignee Priority:
      P2
    • Workaround Exists:
      Yes
    • Workaround Description:
      Use the Sun/Mojarra JSF implementation

      Description

      When using the MyFaces JSF implementation with ICEfaces EE 1.8.2 P04 a ClassCastException is thrown when interacting with the ice:selectInputText component. This error is not thrown when using the Sun/Mojarra implementation.

      Here is the stack trace:

      java.lang.ClassCastException: java.lang.String cannot be cast to java.util.Date
      at com.icesoft.faces.component.selectinputdate.SelectInputDate.validate(SelectInputDate.java:1258)
      at javax.faces.component.UIInput.processValidators(UIInput.java:184)
      at javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:627)
      at javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:627)
      at javax.faces.component.UIForm.processValidators(UIForm.java:73)
      at javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:627)
      at javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:627)
      at javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:627)
      at javax.faces.component.UIViewRoot.processValidators(UIViewRoot.java:149)
      at org.apache.myfaces.lifecycle.ProcessValidationsExecutor.execute(ProcessValidationsExecutor.java:32)
      at org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:95)
      at org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:70)

        Activity

        Hide
        Arran Mccullough added a comment -

        Attached test case that shows issue.

        Steps to reproduce:

        • Run welcomeICEfaces.iface
        • Enter incorrect date say "abcd" in calendar box and tab out
        • An error message will appear below text (calendar) box
        • Now click on Calendar icon
        • Server crashes with exception
        Show
        Arran Mccullough added a comment - Attached test case that shows issue. Steps to reproduce: Run welcomeICEfaces.iface Enter incorrect date say "abcd" in calendar box and tab out An error message will appear below text (calendar) box Now click on Calendar icon Server crashes with exception
        Hide
        Deryk Sinotte added a comment - - edited

        The version of MyFaces that we ship and that was included with the test case is 1.1.5. Because this is a 1.1 implementation rather than a 1.2 implementation, the code in the ViewRootStateManagerImpl.initializeParameters() method:
        try {
        v2DelegateSaveViewMethod = delegate.getClass().getMethod("saveView", new Class[]

        { FacesContext.class}

        );
        } catch (Exception e)

        { log.error("Exception finding JSF1.2 saveView method on delegate", e); }

        Can throw an (apparently non-fatal) exception because it can't find a 1.2 saveView method:
        Oct 16, 2012 10:01:59 AM com.icesoft.faces.application.ViewRootStateManagerImpl initializeParameters
        SEVERE: Exception finding JSF1.2 saveView method on delegate
        java.lang.NoSuchMethodException: org.apache.myfaces.application.jsp.JspStateManagerImpl.saveView(javax.faces.context.FacesContext)
        at java.lang.Class.getMethod(Class.java:1605)
        at com.icesoft.faces.application.ViewRootStateManagerImpl.initializeParameters(ViewRootStateManagerImpl.java:145)
        at com.icesoft.faces.application.ViewRootStateManagerImpl.restoreView(ViewRootStateManagerImpl.java:85)
        at org.apache.myfaces.application.jsp.JspViewHandlerImpl.restoreView(JspViewHandlerImpl.java:231)
        at com.icesoft.faces.application.D2DViewHandler.restoreView(D2DViewHandler.java:216)
        at com.icesoft.faces.application.D2DViewHandler.restoreView(D2DViewHandler.java:216)
        at org.apache.myfaces.lifecycle.RestoreViewExecutor.execute(RestoreViewExecutor.java:81)
        at org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:95)
        at org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:70)
        at javax.faces.webapp.FacesServlet.service(FacesServlet.java:139)
        After discussion with the core group, this wasn't seen as a problem and we had issues with MyFaces 1.2 in the past so upgrading isn't something we are looking to do at the moment. It's possible that the problem only manifests with the included test case. When I ran the component-showcase, I was able to replicate the original issue using the Calendar example but the above exception never appeared.
        As for the original issue, after adding some addition logging and some try/catch blocks, it appears that:

        • When you initially type an invalid date value in the text field, it only validates once, throwing a ConverterException which is handled in a predictable fashion by the framework.
        • When you click on the pop-up calendar icon (with the invalid value still in the text field), you'll see that it validates twice - presumably once for the each sub-component (the calendar and the field).
          This only seems to be a problem with MyFaces. To handle this, I treated the ClassCastException just like the ConverterException:
          } catch (ConverterException ce) { //faces message will be handled by the super class }

          catch (ClassCastException cce )

          { //ICE-8161: MyFaces causes an extra ClassCastException so treat it //the same was as the ConverterException except we don't want to //continue to validate as it's already been done. return; }

          super.validate(context);
          The only difference being that we avoid the secondary validation because it's already failed and been handled by the parent class once. If we let it validate again, you end up with two messages on the client.

        Show
        Deryk Sinotte added a comment - - edited The version of MyFaces that we ship and that was included with the test case is 1.1.5. Because this is a 1.1 implementation rather than a 1.2 implementation, the code in the ViewRootStateManagerImpl.initializeParameters() method: try { v2DelegateSaveViewMethod = delegate.getClass().getMethod("saveView", new Class[] { FacesContext.class} ); } catch (Exception e) { log.error("Exception finding JSF1.2 saveView method on delegate", e); } Can throw an (apparently non-fatal) exception because it can't find a 1.2 saveView method: Oct 16, 2012 10:01:59 AM com.icesoft.faces.application.ViewRootStateManagerImpl initializeParameters SEVERE: Exception finding JSF1.2 saveView method on delegate java.lang.NoSuchMethodException: org.apache.myfaces.application.jsp.JspStateManagerImpl.saveView(javax.faces.context.FacesContext) at java.lang.Class.getMethod(Class.java:1605) at com.icesoft.faces.application.ViewRootStateManagerImpl.initializeParameters(ViewRootStateManagerImpl.java:145) at com.icesoft.faces.application.ViewRootStateManagerImpl.restoreView(ViewRootStateManagerImpl.java:85) at org.apache.myfaces.application.jsp.JspViewHandlerImpl.restoreView(JspViewHandlerImpl.java:231) at com.icesoft.faces.application.D2DViewHandler.restoreView(D2DViewHandler.java:216) at com.icesoft.faces.application.D2DViewHandler.restoreView(D2DViewHandler.java:216) at org.apache.myfaces.lifecycle.RestoreViewExecutor.execute(RestoreViewExecutor.java:81) at org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:95) at org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:70) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:139) After discussion with the core group, this wasn't seen as a problem and we had issues with MyFaces 1.2 in the past so upgrading isn't something we are looking to do at the moment. It's possible that the problem only manifests with the included test case. When I ran the component-showcase, I was able to replicate the original issue using the Calendar example but the above exception never appeared. As for the original issue, after adding some addition logging and some try/catch blocks, it appears that: When you initially type an invalid date value in the text field, it only validates once, throwing a ConverterException which is handled in a predictable fashion by the framework. When you click on the pop-up calendar icon (with the invalid value still in the text field), you'll see that it validates twice - presumably once for the each sub-component (the calendar and the field). This only seems to be a problem with MyFaces. To handle this, I treated the ClassCastException just like the ConverterException: } catch (ConverterException ce) { //faces message will be handled by the super class } catch (ClassCastException cce ) { //ICE-8161: MyFaces causes an extra ClassCastException so treat it //the same was as the ConverterException except we don't want to //continue to validate as it's already been done. return; } super.validate(context); The only difference being that we avoid the secondary validation because it's already failed and been handled by the parent class once. If we let it validate again, you end up with two messages on the client.

          People

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

            Dates

            • Created:
              Updated:
              Resolved: