Details
-
Type:
Bug
-
Status: Open
-
Priority:
Major
-
Resolution: Unresolved
-
Affects Version/s: 1.8.2-EE-GA_P01
-
Fix Version/s: None
-
Component/s: Framework
-
Labels:None
-
Environment:Liferay 5.2.3
Description
The user is using the PortletSession to access their managed beans. When using ui:debug, they are observing that the facesContext.getExternalContext().getSession(false) returns a instance of com.icesoft.faces.webapp.http.servlet.InterceptingServletSession but were expecting com.icesoft.faces.webapp.http.portlet.InterceptingPortletSession.
The facesContext should return an instance of PortletSession since we are inside of a portlet container.
After a brief review, we suspect that the ui:debug works but that the wrong session (servlet instead of portlet) is being provided to the backing beans. From what we have observed using an HTTP sniffer, the ui:debug request is going directly to our servlet context rather than the portal context, which would explain the customer issue above.
The facesContext should return an instance of PortletSession since we are inside of a portlet container.
After a brief review, we suspect that the ui:debug works but that the wrong session (servlet instead of portlet) is being provided to the backing beans. From what we have observed using an HTTP sniffer, the ui:debug request is going directly to our servlet context rather than the portal context, which would explain the customer issue above.
Activity
| Field | Original Value | New Value |
|---|---|---|
| Salesforce Case | [5007000000C3xaM] | |
| Description |
The customer uses the PortletSession to access their managed beans. When using ui:debug, they are observing that the facesContext.getExternalContext().getSession(false) returns a instance of com.icesoft.faces.webapp.http.servlet.InterceptingServletSession but were expecting com.icesoft.faces.webapp.http.portlet.InterceptingPortletSession. The facesContext should return an instance of PortletSession since we are inside of a portlet container. After a brief review, we suspect that the ui:debug works but that the wrong session (servlet instead of portlet) is being provided to the backing beans. From what we have observed using an HTTP sniffer, the ui:debug request is going directly to our servlet context rather than the portal context, which would explain the customer issue above. |
The user is using the PortletSession to access their managed beans. When using ui:debug, they are observing that the facesContext.getExternalContext().getSession(false) returns a instance of com.icesoft.faces.webapp.http.servlet.InterceptingServletSession but were expecting com.icesoft.faces.webapp.http.portlet.InterceptingPortletSession. The facesContext should return an instance of PortletSession since we are inside of a portlet container. After a brief review, we suspect that the ui:debug works but that the wrong session (servlet instead of portlet) is being provided to the backing beans. From what we have observed using an HTTP sniffer, the ui:debug request is going directly to our servlet context rather than the portal context, which would explain the customer issue above. |
This will likely require a custom ui:debug component to support use in Portlets.
Here is a sample request:
http://localhost:8080/SC9239-dataTable-portlet/ICEfacesPage1.iface?facelets.ui.DebugOutput=1277756921380
Either the viewNumber will need to be provided as a request parameter, or the viewNumber will need to be looked up server-side based on the ID passed by facelets.