[ https://issues.apache.org/jira/browse/MYFACES-1531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12476904 ]
David Moss commented on MYFACES-1531: ------------------------------------- FWIW - I had exactly this problem, until I realised that I hadn't included <listener> <listener-class>org.apache.myfaces.webapp.StartupServletContextListener</listener-class> </listener> in my web.xml > Incorrect handling of FacesContext > ---------------------------------- > > Key: MYFACES-1531 > URL: https://issues.apache.org/jira/browse/MYFACES-1531 > Project: MyFaces Core > Issue Type: Bug > Affects Versions: 1.1.4 > Environment: WindowsXP & Solaris; Tomcat 5.5.17, Liferay 4.2.0 > (Portal Server) > Reporter: Olaf Fricke > > We encountered some NPE when accessing the FacesContext in the doView-Method. > I first thought about a bug in the Liferay-Portal-Server (see > http://support.liferay.com/browse/LEP-1869). But then I discovered that it is > a bug in MyFaces, that is triggred because Liferay pools ActionRequest and > RenderRequest objects. > MyFaces changes the external context value in the method > org.apache.myfaces.portlet.MyFacesGenericPortlet#facesRender to switch from > ActionRequest and ActionResponse to RenderRequest and RenderResponse. But > that switch happens to late, so that in doView (and doEdit and doHelp as > well) the FacesContext uses references to the ActionRequest and > ActionResponse instead of RenderRequest and RenderResponse. And unfortunately > Liferay has already recycled the RenderRequest object and thus a NPE is > raised when trying to use the request. > I added the following code to my portlet (indeed, to our own super class) to > make the switch earlier and the NullPointerException when accessing > attributes via the FacesContext will not be raised any longer. (Please note > that I cannot use the FacesContext.getCurrentInstance() method in a portal > environment, because each portlet owns its own context). > public void render(RenderRequest request, RenderResponse response) throws > PortletException, > IOException { > // The following code was taken from > org.apache.myfaces.portlet.MyFacesGenericPortlet#facesRender > // > // get the portlet session local context > ServletFacesContextImpl context = (ServletFacesContextImpl) > request.getPortletSession() > .getAttribute(CURRENT_FACES_CONTEXT); > if (context != null) { > // and set a new external context that uses the render request > and response > context.setExternalContext(makeExternalContext(request, > response)); > } else { > // no context available for the current portlet yet; create a new > one and put it into the session > context = (ServletFacesContextImpl) facesContext(request, > response); > request.getPortletSession().setAttribute(CURRENT_FACES_CONTEXT, > context); > } > super.render(request, response); > } > Later I discovered another problem concerning the FacesContext: When > rendering the very first MyFaces-Portlet, no FacesContext exists for the > Portlet. Therefore the method nonFacesRequest is called. Somewhere inside > this method a new FacesContext is created, but that new FacesContext is never > put into the session. Thus my workaround in the render method was broken > again. I fixed that by extending the method nonFacesRequest as follows: > protected void nonFacesRequest(RenderRequest request, RenderResponse > response) > throws PortletException { > super.nonFacesRequest(request, response); > request.getPortletSession().setAttribute(CURRENT_FACES_CONTEXT, > FacesContext.getCurrentInstance()); > } -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.