Details
-
Type:
Bug
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 3.2
-
Fix Version/s: EE-3.2.0.GA, 3.3
-
Component/s: ACE-Components
-
Labels:None
-
Environment:ICEfaces
-
Assignee Priority:P1
-
Salesforce Case Reference:
Description
This test consists of the default values for the tabSet and tabPane (clientSide=false, cache=none). Each tab has an h:outputText and an ace:dataTable. The behavior they are seeing is that when the first tab is rendered the getter for the list assigned to the ace:dataTable of the second tab content is called. The getter for the outputText in the second tab pane does not get called."
Activity
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
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
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."