[JBoss JIRA] Created: (RF-3576) NullPointerException in AjaxStateManager if using datatable within a form
by Bjoern Eickvonder (JIRA)
NullPointerException in AjaxStateManager if using datatable within a form
-------------------------------------------------------------------------
Key: RF-3576
URL: http://jira.jboss.com/jira/browse/RF-3576
Project: RichFaces
Issue Type: Bug
Affects Versions: 3.2.1
Environment: JSF 1.2 (Sun RI), Facelets, Firefox 2, IBM WSA 6.1, Richfaces 3.2.1 CR8
Reporter: Bjoern Eickvonder
Since at least 3.2.1 CR8 (it did not occur in CR4 or prior) a NullPointerException occurs if using a simple rich:dataTable within a form as follows
<h:form>
<rich:dataTable value="#{test.list}" var="item">
<rich:column>
<h:outputText value="#{item}" />
</rich:column>
</rich:dataTable>
</h:form>
whereby "test" is a request scoped managed bean and "list" a simple list of a few strings. The following exception occurs on accessing that page.
28.05.08 17:01:44:437 CEST] 00000021 viewhandler E Error Rendering View[/test.xhtml]
java.lang.NullPointerException
at org.ajax4jsf.application.AjaxStateManager.getAdditionalState(AjaxStateManager.java:319)
at org.ajax4jsf.application.AjaxStateManager.getComponentStateToSave(AjaxStateManager.java:155)
at org.ajax4jsf.application.AjaxStateManager.buildSerializedView(AjaxStateManager.java:274)
at org.ajax4jsf.application.AjaxStateManager.saveSerializedView(AjaxStateManager.java:257)
at com.sun.facelets.FaceletViewHandler.renderView(FaceletViewHandler.java:615)
at org.ajax4jsf.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:108)
at org.ajax4jsf.application.AjaxViewHandler.renderView(AjaxViewHandler.java:189)
at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:110)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:100)
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:266)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:966)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:907)
at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:145)
at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:154)
at org.ajax4jsf.webapp.BaseFilter.handleRequest(BaseFilter.java:260)
at org.ajax4jsf.webapp.BaseFilter.processUploadsAndHandleRequest(BaseFilter.java:366)
at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:493)
at com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.doFilter(FilterInstanceWrapper.java:190)
at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:130)
at org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal(CharacterEncodingFilter.java:96)
at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:75)
at com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.doFilter(FilterInstanceWrapper.java:190)
at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:130)
at de.bw.TimeFilter.doFilter(TimeFilter.java:23)
at com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.doFilter(FilterInstanceWrapper.java:190)
at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java:130)
at com.ibm.ws.webcontainer.filter.WebAppFilterChain._doFilter(WebAppFilterChain.java:87)
at com.ibm.ws.webcontainer.filter.WebAppFilterManager.doFilter(WebAppFilterManager.java:701)
at com.ibm.ws.webcontainer.filter.WebAppFilterManager.doFilter(WebAppFilterManager.java:646)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:475)
at com.ibm.ws.wswebcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:463)
at com.ibm.ws.webcontainer.servlet.CacheServletWrapper.handleRequest(CacheServletWrapper.java:92)
at com.ibm.ws.webcontainer.WebContainer.handleRequest(WebContainer.java:744)
at com.ibm.ws.wswebcontainer.WebContainer.handleRequest(WebContainer.java:1433)
at com.ibm.ws.webcontainer.channel.WCChannelLink.ready(WCChannelLink.java:93)
at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleDiscrimination(HttpInboundLink.java:465)
at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleNewInformation(HttpInboundLink.java:394)
at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.ready(HttpInboundLink.java:274)
at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.sendToDiscriminators(NewConnectionInitialReadCallback.java:214)
at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.complete(NewConnectionInitialReadCallback.java:113)
at com.ibm.ws.tcp.channel.impl.AioReadCompletionListener.futureCompleted(AioReadCompletionListener.java:152)
at com.ibm.io.async.AbstractAsyncFuture.invokeCallback(AbstractAsyncFuture.java:213)
at com.ibm.io.async.AbstractAsyncFuture.fireCompletionActions(AbstractAsyncFuture.java:195)
at com.ibm.io.async.AsyncFuture.completed(AsyncFuture.java:136)
at com.ibm.io.async.ResultHandler.complete(ResultHandler.java:194)
at com.ibm.io.async.ResultHandler.runEventProcessingLoop(ResultHandler.java:741)
at com.ibm.io.async.ResultHandler$2.run(ResultHandler.java:863)
at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1510)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 3 months
[JBoss JIRA] Created: (RF-3203) KeepAlive description is still incorrect
by Dmitrij Balzer (JIRA)
KeepAlive description is still incorrect
----------------------------------------
Key: RF-3203
URL: http://jira.jboss.com/jira/browse/RF-3203
Project: RichFaces
Issue Type: Bug
Components: doc
Affects Versions: 3.2.0
Reporter: Dmitrij Balzer
Priority: Minor
The KeepAlive description at the livedemo page is still incorrect. I'm pretty sure it should be like the following (i've marked corrected words):
This example will not work as expected. The expression for 'disabled' attribute
equals <false> only after UPDATE MODEL phase when the rsBean properties are
updated with submitted values. So, the component is rendered as enabled
on the RENDER RESPONSE phase.
However, those values do not make sense during the next Ajax request. The
rsBean is created from scratch as soon as it is a new request. JSF makes a
decision what is process on the second (APPLY VALUES) phase. At this moment,
the expression for 'disabled' still equals <true>. Therefore, the processing
for button is bypassed. The action <isn't> invoked as a result.
phase <excess word here?>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 3 months