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
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)
-
Hide
- Case11235Example.war
- 7.53 MB
- Arran Mccullough
-
- META-INF/MANIFEST.MF 0.1 kB
- META-INF/context.xml 0.1 kB
- WEB-INF/classes/.../example/TestBean.class 0.7 kB
- WEB-INF/faces-config.xml 0.8 kB
- WEB-INF/lib/FastInfoset.jar 281 kB
- WEB-INF/lib/backport-util-concurrent.jar 316 kB
- WEB-INF/lib/commons-beanutils.jar 226 kB
- WEB-INF/lib/commons-collections.jar 558 kB
- WEB-INF/lib/commons-digester.jar 140 kB
- WEB-INF/lib/commons-discovery.jar 75 kB
- WEB-INF/lib/commons-el.jar 110 kB
- WEB-INF/lib/commons-fileupload.jar 56 kB
- WEB-INF/lib/commons-lang.jar 240 kB
- WEB-INF/lib/commons-logging.jar 52 kB
- WEB-INF/lib/icefaces-comps.jar 1.75 MB
- WEB-INF/lib/icefaces-facelets.jar 596 kB
- WEB-INF/lib/icefaces.jar 1.22 MB
- WEB-INF/lib/jstl.jar 20 kB
- WEB-INF/lib/jxl.jar 689 kB
- WEB-INF/.../krysalis-jCharts-1.0.0-alpha-1.jar 148 kB
- WEB-INF/lib/myfaces-api.jar 246 kB
- WEB-INF/lib/myfaces-impl.jar 531 kB
- WEB-INF/lib/standard.jar 380 kB
- WEB-INF/web.xml 4 kB
- welcomeICEfaces.jspx 1 kB
-
- Case11235Example.zip
- 20 kB
- Arran Mccullough
Activity
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
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[]
);
} 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:
- 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.
Attached test case that shows issue.
Steps to reproduce: