Details
-
Type: Bug
-
Status: Closed
-
Priority: 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)
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)
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:
{ FacesContext.class}try {
v2DelegateSaveViewMethod = delegate.getClass().getMethod("saveView", new Class[]
);
{ log.error("Exception finding JSF1.2 saveView method on delegate", e); }} catch (Exception 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:
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.