Mark: "Ok, here's the relevant part of the stacktrace, which was the same for the current and non-current tabs' components:

at org.icefaces.ace.component.datatable.DataTable.setRowIndex(DataTable.java:450)
at org.icefaces.ace.component.datatable.DataTable.visitTree(DataTable.java:1442)
at javax.faces.component.UIComponent.visitTree(UIComponent.java:1601)
at javax.faces.component.UIComponent.visitTree(UIComponent.java:1601)
at javax.faces.component.UIComponent.visitTree(UIComponent.java:1601)
at javax.faces.component.UIForm.visitTree(UIForm.java:344)
at javax.faces.component.UIComponent.visitTree(UIComponent.java:1601)
at javax.faces.component.UIComponent.visitTree(UIComponent.java:1601)
at org.icefaces.impl.event.RestoreResourceDependencies.processEvent(RestoreResourceDependencies.java:24)
at javax.faces.event.SystemEvent.processListener(SystemEvent.java:106)
at com.sun.faces.application.ApplicationImpl.processListeners(ApplicationImpl.java:2168)
at com.sun.faces.application.ApplicationImpl.invokeListenersFor(ApplicationImpl.java:2144)
at com.sun.faces.application.ApplicationImpl.publishEvent(ApplicationImpl.java:302)
at com.sun.faces.application.ApplicationImpl.publishEvent(ApplicationImpl.java:246)
at javax.faces.component.UIComponentBase.encodeBegin(UIComponentBase.java:812)
at javax.faces.component.UIViewRoot.encodeBegin(UIViewRoot.java:962)

Basically, our code in RestoreResourceDependencies is doing a visitTree, which probably doesn't require UIData iteration, but is not setting the visitTree hint to that effect. Up until now, I've only seen state saving and restoration need to set that hint, but it looks like this is another example.

In RestoreResourceDependencies, we call VisitContext.createVisitContext(FacesContext), and we should instead call VisitContext.createVisitContext(FacesContext context, null, Set<VisitHint> hints), with an EnumSet containing VisitHint.SKIP_ITERATION. There are a couple hints there, and SKIP_UNRENDERED might be relevant as well."

Attached test case that demonstrates the reported behavior.

Modified DataTable component to test for Myfaces environment before resetting the data model, whenever that was meant to fix a Myfaces issue. Also modified RestoreResourceDependencies to provide the SKIP_ITERATION hint whn visiting the tree, this way the data table will not access its data model and indirectly the backing beans.

The bean getters are now accessed only during apply values, process validation, update model and invoke application phases as per TabSet described behaviour:

"When a tabSet is in server mode, and changes tabs from the old one to
the new one, the old one is executed and the new one is rendered. In
client mode, if the server has been contacted, they all execute. This
method is used by the TabPane(s) to control their execution."

If we intend to go even further to use a cached data model value which will truly get rid of all the bean getter invocations the DataTable component class will need to be modified so that setRowIndex(-1) method is not called anymore. When this method is called with -1 as parameter the cached data model is cleared causing the component to recalculate its data model.

Mircea, as nice a simplification as it would be to prevent the component from ever clearing its cached model, I don't think it's task we'll be able to invest the huge amount of required time in (particularly as a speculative optimization). In addition to the question of why the model would be being cleared it if wasn't necessary for at least some situations.

The component often checks to see if the index is -1 to handle special unindexed iterations. e.g the -1 index is the only index that causes the implementation of getClientId to return an a table ID without an index, which is particularly important as it is the key for DataTable component state. There are many place in state saving and visiting that the 'unset' index is required.

In addition setRowIndex(-1) called throughout the UIData superclass implementations of the MyFaces and Mojarra. Though large parts of these have been overridden, a very large time investment would need to be made to override the rest of these cases (in a way appropriate for both impls), and remove setRowIndex, substitute some new mechanism in the logic, and then test both MyFaces and Mojarra throughly.

I wouldn't suggest pursuing redevelopment of such a quirk-filled and wide reaching UIData API feature unless absolutely necessary.

Re-opening due to errors that occur when running the samples' tests in automation.
In automation, the first test in the test suite fails because of an HTTP error 500 (see also attachment):
HTTP Status 500 -

type Exception report

message

description The server encountered an internal error () that prevented it from fulfilling this request.

exception

java.lang.NullPointerException
javax.faces.component.UIViewRoot$ViewMap.clear(UIViewRoot.java:1779)
com.sun.faces.config.InitFacesContext.release(InitFacesContext.java:239)
javax.faces.webapp.FacesServlet.service(FacesServlet.java:577)
note The full stack trace of the root cause is available in the Apache Tomcat/6.0.26 logs.

In tomcat log, the error is:
17-Dec-2012 4:14:08 PM org.apache.catalina.core.StandardWrapperValve invoke
SEVERE: Servlet.service() for servlet Faces Servlet threw exception
java.lang.NullPointerException
at javax.faces.component.UIViewRoot$ViewMap.clear(UIViewRoot.java:1779)
at com.sun.faces.config.InitFacesContext.release(InitFacesContext.java:239)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:577)
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:298)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:852)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:588)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)
at java.lang.Thread.run(Thread.java:662)

This error is not an issue when deploying/testing manually.

Note that this revision is when the failures begin in automation.

The same errors occur when running in automation the ACE tests, 3.0 Regression tests, or the tutorials' tests.

This NullPointerException is not caused by our code. It is most probably a Mojarra thread related issue regarding how FacesContext is setup at the application startup. The InitFacesContext implementation is used only on application startup, ICEfaces doesn't even get a chance to run. When the ViewMap is cleared it seems the current FacesContext is not set.

Also, this exception occurred well before the last fix for ICE-8798 was checked in, see ICE-8752. I believe this last problem should be pursued as a separate JIRA case.

Created follow up issue for the NPE problem: ICE-8851