[
https://issues.apache.org/jira/browse/TRINIDAD-1639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12791738#action_12791738
]
Gabrielle Crawford commented on TRINIDAD-1639:
----------------------------------------------
I'm about to check in a fix so that in PartialViewContextImpl.renderState there
is a state string, but there's still an exception, I've filed a new issue for
the new exception
https://issues.apache.org/jira/browse/TRINIDAD-1660
> NPE thrown when ResponseStateManagerImpl returns a null state - on
> partialSubmit using a JSF 2.0 Ajax APIs...
> -------------------------------------------------------------------------------------------------------------
>
> Key: TRINIDAD-1639
> URL: https://issues.apache.org/jira/browse/TRINIDAD-1639
> Project: MyFaces Trinidad
> Issue Type: New Feature
> Components: Components
> Affects Versions: 2.0.0-core
> Environment: 1. javax.faces.FACELETS_VIEW_MAPPINGS: *.jspx
> 2. Uses JSF 2.0 libraries
> 3.Partial State Saving is off
> Reporter: Pavitra Subramaniam
> Assignee: Gabrielle Crawford
> Attachments: ajaxPPRDemos.jspx
>
>
> 1. User clicks on command titled 'partialSubmit', that has both
> partialSubmit=true set and has an onclick event handler using the new JSF
> Ajax API.
> - Since the Trinidad Ajax code works independently today of JSF 2.0 Ajax
> framework, you will see the 2 JS on click handler chained for the same action
> event. Typically, if the first one succeeds the second one is ignored.
> 2. In this usecase (see attached demo code), the first request to the server
> is the JSF 2.0 Ajax request. In the renderResponse phase, the code in
> CoreResponseStateManager returns null for getViewState() which causes the NPE
> as a null value is being written into the writer
> (PartialViewContextImpl$DelayedInitPartialResponseWriter).
> The call stack is as follows:
> <FaceletViewHandlingStrategy><handleRenderException> Error Rendering
> View[/demos/ajaxPPRDemos.jspx]
> java.lang.NullPointerException
> at java.io.Writer.write(Writer.java:140)
> at
> com.sun.faces.context.PartialViewContextImpl.renderState(PartialViewContextImpl.java:395)
> at
> com.sun.faces.context.PartialViewContextImpl.processPartial(PartialViewContextImpl.java:292)
> at javax.faces.component.UIViewRoot.encodeChildren(UIViewRoot.java:988)
> at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1610)
> at
> com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:368)
> at
> com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewHandler.java:126)
> at
> javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:273)
> at
> org.apache.myfaces.portlet.faces.application.PortletViewHandlerImpl.renderView(PortletViewHandlerImpl.java:200)
> at
> javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:273)
> at
> org.apache.myfaces.trinidadinternal.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:208)
> at
> com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:127)
> at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
> ...
> 3. Because the first one fails the second one which is a Trinidad PPR submit
> goes through fine. It may very well be that in the future Trinidad PPR may
> end up using the JSF Ajax API, but in the meantime, it may be worth
> investigating if the above exception is valid or a symptom of an invalid
> usecase.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
