Details
-
Type: Bug
-
Status: Closed
-
Priority: Major
-
Resolution: Won't Fix
-
Affects Version/s: EE-1.8.2.GA_P04
-
Fix Version/s: EE-1.8.2.GA_P05
-
Component/s: ICE-Components
-
Labels:None
-
Environment:ICEfaces EE 1.8.2 P04
-
Assignee Priority:P2
-
Workaround Exists:Yes
-
Workaround Description:Use Ajax Push APIs (e.g. SessionRenderer) on non-JSF threads.
Description
Customer Use case/Scenario: In a few scenarios we need to get data from database in a thread. After successful get we call gotoFirstPage() on the DataPaginator to move to the first page.
Error Stack Trace:
Exception in thread "Thread-13" java.lang.NullPointerException
at com.icesoft.faces.component.datapaginator.DataPaginatorGroup.execute(DataPaginatorGroup.java:33)
at com.icesoft.faces.component.datapaginator.DataPaginator.gotoFirstPage(DataPaginator.java:963)
at com.icefaces.test.SearchManager$1.run(SearchManager.java:55)
Issue is likely due to the changes made in
-
Hide
- Case11257Example.war
- 7.27 MB
- Arran Mccullough
-
- META-INF/MANIFEST.MF 0.1 kB
- META-INF/context.xml 0.1 kB
- WEB-INF/classes/com/.../test/Alert.class 0.5 kB
- WEB-INF/classes/com/.../test/Globals.class 0.3 kB
- WEB-INF/classes/.../SearchManager$1.class 1.0 kB
- WEB-INF/classes/.../test/SearchManager.class 2 kB
- WEB-INF/faces-config.xml 1 kB
- WEB-INF/lib/FastInfoset.jar 281 kB
- WEB-INF/lib/backport-util-concurrent.jar 316 kB
- WEB-INF/lib/commons-beanutils.jar 113 kB
- WEB-INF/lib/commons-collections.jar 162 kB
- WEB-INF/lib/commons-digester.jar 104 kB
- WEB-INF/lib/commons-fileupload.jar 56 kB
- WEB-INF/lib/commons-logging.jar 30 kB
- WEB-INF/lib/icefaces-comps.jar 1.75 MB
- WEB-INF/lib/icefaces-facelets.jar 592 kB
- WEB-INF/lib/icefaces.jar 1.22 MB
- WEB-INF/lib/jsf-api.jar 312 kB
- WEB-INF/lib/jsf-impl.jar 1.14 MB
- WEB-INF/lib/jstl.jar 20 kB
- WEB-INF/lib/jxl.jar 689 kB
- WEB-INF/.../krysalis-jCharts-1.0.0-alpha-1.jar 148 kB
- WEB-INF/lib/standard.jar 380 kB
- WEB-INF/web.xml 4 kB
- inc/images/arrow-ff.gif 1 kB
- inc/images/arrow-first.gif 1 kB
- inc/images/arrow-fr.gif 1 kB
- inc/images/arrow-last.gif 1 kB
- inc/images/arrow-next.gif 1 kB
- inc/images/arrow-previous.gif 1 kB
-
- Case11257Example.zip
- 29 kB
- Arran Mccullough
-
- SearchManager.java
- 3 kB
- Deryk Sinotte
Activity
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
The DataPaginatorGroup class was only recently added to support the desired behaviour described in ICE-7378 and contains the following method where the NPE occurs:
public static void execute(UIData uiData, Invoker invoker) {
if (uiData== null || !uiData.getAttributes().containsKey(DataPaginatorGroup.class.getName())) return;
List dataPaginatorClientIdList = (List) uiData.getAttributes().get(DataPaginatorGroup.class.getName());
Iterator it = dataPaginatorClientIdList.iterator();
while (it.hasNext()) {
UIComponent component = D2DViewHandler.findComponent(":" + it.next(), FacesContext.getCurrentInstance().getViewRoot());
if (component != null && component.isRendered() &&
component instanceof DataPaginator)
}
}
The problem is that, since this is a non-JSF thread, there is no FacesContext so FacesContext.getCurrentInstance() returns null. In order to achieve the desired result, the call will have to be made on a JSF thread, which may mean using a Push + PortableRenderer.
Sorry...this is ICEfaces 1.8 so there is no PortableRenderer. I'll have to look closer at the test case and see if there's a way to workaround it using Push or something.
Re-opening to attach a possible workaround.
The test case shows what can happen when attempting to do JSF based operations on a non-JSF thread. While it can work (like it did in the past) it's certainly not guaranteed. Especially when the components need access to a valid FacesContext to do the work.
However, it is possible to use Ajax Push in many of these situations and it's what we generally recommend when trying to offload long running operations onto another thread. When the work completes, call a server-side render to ensure the most recent state is sent back to the client.
I'm attaching a modified version of the SearchManager class that uses the SessionRenderer API to accomplish the same goal as the original test case. I've added comments where appropriate. Hopefully this type of approach can be used to get around the problem.
Modified SearchManager class that uses SessionRenderer and some other logic to reset the DataPaginator location when appropriate.
Closing again. Added example of alternative approach and related comments.
Attached test case that shows issue.
Steps: