Details
-
Type:
New Feature
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 2.0.2
-
Component/s: Framework
-
Labels:None
-
Environment:ICEfaces 2, ACE 2.1
-
Assignee Priority:P2
-
Workaround Exists:Yes
-
Workaround Description:Disable the DOM differencing of this component, or of all partial updates.
Description
In org.icefaces.impl.context.DOMPartialRenderCallback.visit(-), around line 458, we find the position of the root of the component, by assuming the component clientId is the id of the root DOM element. We then remove the whole DOM sub-tree corresponding to that component, and setup the DOM cursor so that the component may fully render itself in the vacated space. We then search for the new elements by the clientId, so that we can compare the old sub-tree to the new sub-tree. But if the newly rendered output is not of the whole component, the search for the clientId fails, and we get a NPE.
What needs to be done, is to allow the component to render itself first, adjacent to the old rendering of itself. And then the id of the top-most newly rendered element should be used to find the corresponding old element. If the new top-most element does not have an id, or if it's not found in the old rendering, then the update should just be sent to the browser, without any DOM differencing, and the bridge will deal with it. If the corresponding old element is found, then that old sub-tree may be scraped out, the new sub-tree supplanted in it's place, and the differencing done, so that the optimal change set can be transmitted. In most cases, the top element ids will be the clientId, and it will be the whole component being swapped in, but in special new ACE scenarios, it will be the sub-component regions.
-
Hide
-
-
META-INF/MANIFEST.MF
-
ICEfacesPage1.xhtml
-
WEB-INF/.../AccordionPanelBean$1.class
-
WEB-INF/.../AccordionPanelBean$Counter.class
-
WEB-INF/classes/.../AccordionPanelBean.class
-
WEB-INF/.../AccordionPanelTableBean.class
-
WEB-INF/faces-config.xml
-
WEB-INF/web.xml
-
accordionPanelAttribute.xhtml
-
accordionPanelDataTbl.xhtml
-
accordionPanelIceTabSet.xhtml
-
accordionPanelPnlTabSet.xhtml
-
accordionPanelPush.xhtml
-
accordionPanelRepeat.xhtml
-
accordionPanelRepeatDataTbl.xhtml
-
accordionPanelTblBttm.xhtml
-
accordionPanelTblTop.xhtml
-
index.jsp
-
readme.txt
-
start.xhtml
-
WEB-INF/lib/icefaces-ace.jar
-
WEB-INF/lib/icefaces-compat.jar
-
WEB-INF/lib/icefaces.jar
-
WEB-INF/lib/icepush.jar
-
WEB-INF/lib/commons-logging.jar
-
WEB-INF/lib/jstl.jar
-
WEB-INF/lib/javax.faces.jar
-
-
-
Hide
-
-
META-INF/MANIFEST.MF
-
ICEfacesPage1.xhtml
-
WEB-INF/.../AccordionPanelBean$1.class
-
WEB-INF/.../AccordionPanelBean$Counter.class
-
WEB-INF/classes/.../AccordionPanelBean.class
-
WEB-INF/.../AccordionPanelTableBean.class
-
WEB-INF/faces-config.xml
-
WEB-INF/web.xml
-
accordionPanelAttribute.xhtml
-
accordionPanelDataTbl.xhtml
-
accordionPanelIceTabSet.xhtml
-
accordionPanelPnlTabSet.xhtml
-
accordionPanelPush.xhtml
-
accordionPanelRepeat.xhtml
-
accordionPanelRepeatDataTbl.xhtml
-
accordionPanelTblBttm.xhtml
-
accordionPanelTblTop.xhtml
-
index.jsp
-
readme.txt
-
start.xhtml
-
WEB-INF/lib/icefaces-ace.jar
-
WEB-INF/lib/icefaces-compat.jar
-
WEB-INF/lib/icefaces.jar
-
WEB-INF/lib/icepush.jar
-
WEB-INF/lib/commons-logging.jar
-
WEB-INF/lib/jstl.jar
-
WEB-INF/lib/javax.faces.jar
-
-
Activity
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
Attached test case, where problem is seen again (accordionPanel.war).
Steps to reproduce:
1. Deploy the application.
2. Navigate to http://localhost:8080/accordionPanel/accordionPanelAttribute.jsf
3. Check the checkbox next to 'dynamic'.
4. Click on any of the closed tabs in the accordion panel.
5. The tab will not open and the following exception is thrown in the console:
14-Sep-2011 1:58:11 PM org.icefaces.impl.util.DOMUtils nodeDiff
SEVERE: Pruning failure
java.lang.NullPointerException
at org.icefaces.impl.util.DOMUtils.compareNodes(DOMUtils.java:419)
at org.icefaces.impl.util.DOMUtils.nodeDiff(DOMUtils.java:394)
at org.icefaces.impl.context.DOMPartialRenderCallback.visit(DOMPartialViewContext.java:513)
at com.sun.faces.component.visit.PartialVisitContext.invokeVisitCallback(PartialVisitContext.java:183)
at javax.faces.component.UIComponent.visitTree(UIComponent.java:1589)
at javax.faces.component.UIComponent.visitTree(UIComponent.java:1600)
at javax.faces.component.UIForm.visitTree(UIForm.java:344)
at javax.faces.component.UIComponent.visitTree(UIComponent.java:1600)
at javax.faces.component.UIComponent.visitTree(UIComponent.java:1600)
at org.icefaces.impl.context.DOMPartialViewContext.renderSubtrees(DOMPartialViewContext.java:330)
at org.icefaces.impl.context.DOMPartialViewContext.processPartial(DOMPartialViewContext.java:160)
at javax.faces.component.UIViewRoot.encodeChildren(UIViewRoot.java:981)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1756)
at com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:390)
at com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewHandler.java:131)
at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:121)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:594)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:291)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:859)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:602)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)
at java.lang.Thread.run(Thread.java:662)
Is there anything unusual that is being written to the DOM that might cause this?
Carmen detected this problem in her test app (attached). This problem doesn't happen in comp-suite. I wonder if it has anything to do with the fact that the 'dynamic' attribute is being set dynamically?
Changes have been checked in to avoid the Exception and handle the case below:
Subtree rendering for panelForm2:panelId oldSubtree: [div: null] newSubtree: null
Subtree rendering for panelForm2:panelId oldSubtree: null newSubtree: null
No matter what accordion tab is clicked on, the same subtree is requested to be rendered, and it is eventually null in the DOM, meaning that no element with id "panelForm2:panelId" is found in the DOM. The corrected behavior for the DOM diff is now to produce a "delete" operation when the subtree is null. This may not be the desired effect for the component, so the component should potentially render an empty div in all cases.
For instance, the following is acceptable since subtree rendering can add and remove components when rendered from "top":
<h:panelGroup id="top">
<h:panelGroup id="inner" rendered="#
</h:panelGroup>
The following will work only once and then fail from then on:
<h:panelGroup id="top" rendered="#{bean.rendered}
">
<h:panelGroup id="inner" />
</h:panelGroup>
Once top is not rendered, it cannot be added again via subtree rendering.
It may make sense to add WARNING level logging for these unrecoverable subtree rendering cases.
If the ProjectStage is not Production, the following WARNING messages will be generated for these rendering cases:
WARNING: Subtree rendering deleting panelForm2:panelId and subsequent updates may fail.
WARNING: Subtree rendering for panelForm2:panelId may not exist on client and replace may fail.
So, the recommendation is to run the test in Development mode:
<context-param>
<param-name>javax.faces.PROJECT_STAGE</param-name>
<param-value>Development</param-value>
</context-param>
and modify the component so that it does not delete the DOM subtree it will use for updating.
After applying the changes to the accordionPanel test case (accordionPanel.war), there is no NullPointerException error, but the accordionPanel is not working properly after setting the attribute dynamic = true:
- the content of the active tab is not displayed on the page (screenshot1 attached).
- selecting any of the closed tabs will make all the tabs of the component disappear, and only the content of the selected tab will render on the page. (screenshot 2 attached). The updated .war file is also attached.
This should now be fixed – the component was not indicating that it required customUpdate, causing the response to corrupt the component. (Inspecting the renderer shows that containing div elements are rendered.)
To verify that this feature is working as expected we should create a new ace:dataTable regression test:
Make test for dataTable row selection that will result in a custom update extension in the response, as well as use the onRowSelectUpdate to specify a region of the page to get a regular jsf update (make sure it changes so dom diff won't suppress), and also make the server side listener use JavascriptRunner to make the response also have an eval section. This way we can test all 3 types of things in the response.
These changes have been tested for the ace accordionPanel component using code Rev# 25567, on tomcat6, and this works well in Firefox 3.6, Firefox 6 and Gchrome 14.
In IE8 browser, the dynamic attribute still doesn't work: after setting dynamic=true, when clicking on one of the closed tabs, the accordionPanel component disappears from the page.
Completed test. Works as expected.
Tested again the ace accordionPanel - dynamic attribute using code rev#25636, and found the issue described above has been fixed.
This has been verified on browsers: IE8, IE7, Firefox 3.6, Gchrome 14, using tomcat6 as server.
Right now we could use the technique from
ICE-6950for TabView, to make it specifically opt out of DOM differencing for partial updates. It seems thatICE-6950was made for 2 scenarios, the JSON response, and these sub-component responses, when maybeICE-6950should only be used for the JSON response issue, and this jiraICE-7032should be for the sub-component issue.