Details
Bug
Major
Description
(note, line numbers may not match as this stack trace is from classes that have extra debugging lines in them)
java.lang.NullPointerException
at org.icefaces.impl.util.DOMUtils.printNode(DOMUtils.java:291)
at org.icefaces.impl.util.DOMUtils.printNodeCDATA(DOMUtils.java:278)
at org.icefaces.impl.context.DOMPartialViewContext.processPartial(DOMPartialViewContext.java:189)
at javax.faces.component.UIViewRoot.encodeChildren(UIViewRoot.java:981)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1757)
at com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:391)
at com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewHandler.java:131)
at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:288)
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 com.liferay.faces.bridge.lifecycle.LifecycleWrapper.render(LifecycleWrapper.java:45)
at com.liferay.faces.bridge.BridgePhaseResourceImpl.execute(BridgePhaseResourceImpl.java:115)
at com.liferay.faces.bridge.BridgeImpl.doFacesRequest(BridgeImpl.java:115)
at javax.portlet.faces.GenericFacesPortlet.serveResource(GenericFacesPortlet.java:178)
Activity
| Field | Original Value | New Value |
|---|---|---|
| Salesforce Case | [] | |
| Assignee Priority | P1 | |
| Assignee | Deryk Sinotte [ deryk.sinotte ] |
| Repository | Revision | Date | User | Message |
| ICEsoft Public SVN Repository | #30044 | Tue Jul 17 15:30:22 MDT 2012 | deryk.sinotte | |
| Files Changed | ||||
MODIFY
/icefaces3/trunk/icefaces/core/src/main/java/org/icefaces/impl/context/DOMPartialViewContext.java
|
The real problem turned out to be in the DOMPartialViewContext. As part of the fix for ICE-8132, "full page" udpates were split into separate <head> and <body> updates. As part of the changes, the following lines were included:
Node body = newDOM.getElementsByTagName("body").item(0);
partialWriter.startUpdate(JAVAX_FACES_VIEW_BODY);
Unfortunately, when a new DOM is generated for a portlet, there is no "body" to get which leads to the NPE. The old way of doing it just used the whole document (which is why the fix was required).
So to fix this, I went back to a version of the original way if there is no body and where running as a portlet:
Deryks-MacBook-Pro:core deryk$ svn diff -r30043:30044
Index: src/main/java/org/icefaces/impl/context/DOMPartialViewContext.java
===================================================================
— src/main/java/org/icefaces/impl/context/DOMPartialViewContext.java (revision 30043)
+++ src/main/java/org/icefaces/impl/context/DOMPartialViewContext.java (revision 30044)
@@ -46,6 +46,7 @@
public class DOMPartialViewContext extends PartialViewContextWrapper
Node body = newDOM.getElementsByTagName("body").item(0);
- partialWriter.startUpdate(JAVAX_FACES_VIEW_BODY);
+ String target = JAVAX_FACES_VIEW_BODY;
+
+ //ICE-8379: If there is no body in the new DOM, then it's likely were running
+ // in a portlet so get the document as it will be a "fragment" of the page. We
+ // also need to just target the ViewRoot rather than the ViewBody for the update.
+ if (body == null &&
+ EnvUtils.instanceofPortletRequest(facesContext.getExternalContext().getRequest())) { + body = newDOM.getDocumentElement(); + target = JAVAX_FACES_VIEW_ROOT; + }+
+ partialWriter.startUpdate(target);
DOMUtils.printNodeCDATA(body, outputWriter);
partialWriter.endUpdate();
} else if (null != diffs) {
| Status | Open [ 1 ] | Resolved [ 5 ] |
| Resolution | Fixed [ 1 ] |
| Status | Resolved [ 5 ] | Closed [ 6 ] |
I could reproduce the behaviour initially reported by Neil and it looked like it was related to navigation and our PropagatingNavigationHandler.
The form submission triggers a non-redirect navigation (to a thank-you type confirmation screen after the form has been successfully filled out). For this type of navigation, we rely on storing the original DOM in the view map and pulling it out to do the comparison and then basically replacing the contents of the body. The DOM is put into the view map in PropagatingNavigationHandler.handleNavigation():
...
{ viewMap.put(DOMResponseWriter.OLD_DOM, oldDOM); }NavigationCase navigationCase = getNavigationCase(context, fromAction, outcome);
if (navigationCase != null && !navigationCase.isRedirect()) {
viewMap = viewRoot.getViewMap();
viewMap.putAll(propagated);
if (null != oldDOM)
...
Logging the various bits before and after the NavigationHandlers have all run:
PropagatingNavigationHandler.handleNavigation: PRE
{applicantBackingBean.submit}oldDOM get: [#document: null]
view root : com.liferay.faces.bridge.component.UIViewRootBridgeImpl@61fa0030
from : #
outcome : success
20:34:53,493 DEBUG [ViewHandlerImpl:55] Creating view for viewId=[/views/confirmation.xhtml]
PropagatingNavigationHandler.handleNavigation: POST
oldDOM get: null
view root : com.liferay.faces.bridge.component.UIViewRootBridgeImpl@1b541798
from : #{applicantBackingBean.submit}
outcome : success
PropagatingNavigationHandler.handleNavigation
navigation case: null
The navigationCase is currently coming back null so the oldDOM is not being added back in to the new view map for the new view root. However, this behaviour was the same as with ICEfaces 3.0.1 and I went back and confirmed that the example app works with that version. So this is not the actual problem.