myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gabrielle Crawford (JIRA)" <>
Subject [jira] Commented: (TRINIDAD-1639) NPE thrown when ResponseStateManagerImpl returns a null state - on partialSubmit using a JSF 2.0 Ajax APIs...
Date Thu, 17 Dec 2009 04:12:18 GMT


Gabrielle Crawford commented on TRINIDAD-1639:

looks like 1660 is a dup, after pulling the latest code I get no exceptions

> NPE thrown when ResponseStateManagerImpl returns a null state - on partialSubmit using
a JSF 2.0 Ajax APIs...
> -------------------------------------------------------------------------------------------------------------
>                 Key: TRINIDAD-1639
>                 URL:
>             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
>             Fix For: 2.0.0-core
>         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
> The call stack is as follows:
> <FaceletViewHandlingStrategy><handleRenderException> Error Rendering View[/demos/ajaxPPRDemos.jspx]
> java.lang.NullPointerException
> 	at
> 	at com.sun.faces.context.PartialViewContextImpl.renderState(
> 	at com.sun.faces.context.PartialViewContextImpl.processPartial(
> 	at javax.faces.component.UIViewRoot.encodeChildren(
> 	at javax.faces.component.UIComponent.encodeAll(
> 	at com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView(
> 	at com.sun.faces.application.view.MultiViewHandler.renderView(
> 	at javax.faces.application.ViewHandlerWrapper.renderView(
> 	at org.apache.myfaces.portlet.faces.application.PortletViewHandlerImpl.renderView(
> 	at javax.faces.application.ViewHandlerWrapper.renderView(
> 	at org.apache.myfaces.trinidadinternal.application.ViewHandlerImpl.renderView(
> 	at com.sun.faces.lifecycle.RenderResponsePhase.execute(
> 	at com.sun.faces.lifecycle.Phase.doPhase(
> ...
> 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.

View raw message