Can not render jsf portlet - UnsupportedOperationException

[Adam Nowak, modifié il y a 10 années.]

Hi all,


Some time ago was decided in my company to upgrade liferay from version 5.2.3 to newest one, 6.1.1.
Myfaces is used by us as portlet implementation. We used to use version 1.1.6 but I had to upgrade myfaces to version 1.2.12 because jsf 1.1 is not supported by liferay faces bridges.
I have also made all necessary changes to run all custom jsf components that we are using.
So my current configuration is:
Liferay 6.1.1.
Myfaces 1.2.12
liferay-faces-bridge 2.1.1-ga2

One of our portlet is a portlet which contains one main jsf component which builds jsf components tree dynamically based on some configuration and next render the components tree as a form to a user. This logic is implemented in setProperties() method of the main custom component.
I tried to run the portlet with no changes made in jsp documents but i got following error:

08:43:54,347 ERROR [http-bio-8080-exec-93][render_portlet_jsp:154] java.lang.UnsupportedOperationException
        at com.liferay.faces.bridge.filter.HttpServletRequestAdapter.getSession(HttpServletRequestAdapter.java:346)
        at org.apache.myfaces.application.jsp.JspViewHandlerImpl.renderView(JspViewHandlerImpl.java:347)
        at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:48)
        at com.liferay.faces.bridge.application.ViewHandlerCompatImpl._renderView(ViewHandlerCompatImpl.java:116)
        at com.liferay.faces.bridge.application.ViewHandlerCompatImpl.renderView(ViewHandlerCompatImpl.java:72)
        at org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:41)
        at org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:140)
        at com.liferay.faces.bridge.lifecycle.LifecycleWrapper.render(LifecycleWrapper.java:46)
        at org.apache.myfaces.custom.ppr.PPRLifecycleWrapper.render(PPRLifecycleWrapper.java:84)
        at com.liferay.faces.bridge.BridgePhaseRenderImpl.execute(BridgePhaseRenderImpl.java:227)
        at com.liferay.faces.bridge.BridgePhaseRenderImpl.execute(BridgePhaseRenderImpl.java:85)
        at com.liferay.faces.bridge.BridgeImpl.doFacesRequest(BridgeImpl.java:112)
        at javax.portlet.faces.GenericFacesPortlet.doView(GenericFacesPortlet.java:255)
        at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:328)
        at javax.portlet.faces.GenericFacesPortlet.doDispatch(GenericFacesPortlet.java:204)
        at javax.portlet.GenericPortlet.render(GenericPortlet.java:233)

below is a myfaces code which invokes getSession on request adapter which cause problem:

	// handle character encoding as of section 2.5.2.2 of JSF 1.1
        if (externalContext.getRequest() instanceof HttpServletRequest)
        {
            HttpServletRequest httpServletRequest = (HttpServletRequest) externalContext.getRequest();
            HttpSession session = httpServletRequest.getSession(false);

            if (session != null)
            {
                session.setAttribute(ViewHandler.CHARACTER_ENCODING_KEY, response.getCharacterEncoding());
            }
        }

I couldn't figured out what is wrong so i decided to try to run my portlet with view documents implemented as a facelet instead of jsp mixed with jsf.
I have migrate jsp documents to xhtml documents and i changed view-handler implementatio in faces-config.xml
to the

 <view-handler>com.liferay.faces.bridge.application.ViewHandlerFaceletImpl</view-handler>

.
It went partially great because my portlet finally displayed configuration form but on the other hand a form builded dynamically was not displayed at all. It realized me that setProperties() method was never called therefore there were no components to render in the jsf tree. Some additional research realized me that this is perfectly normal that the setProperties method is not called.

I can see two solutions to my problem:
1. Use facelets and move logic of my component from setProperties() method to an appropriate place such as ComponentHandler (as described here http://www.nofluffjuststuff.com/blog/ed_burns/2009/10/jsf2_facelet_tag_handlers). This is less prefered solution because of many legacy jsp documents and some java code placed in setProperties() which will have to be migrated.
2. Get rid of this render portlet error. This is the best solution but i don't know how to achieve it because i don't know where the problem is.

What do you think?

I will appreciate any help with this issue.

Best regards,
Adam.

[Neil Griffin, modifié il y a 10 années.]

The code in MyFaces Core that is calling httpServletRequest.getSession(false) is a bug in MyFaces. Instead, MyFaces should call ExternalContext.getSession(false), and then ExternalContext.getSessionMap().put() in order to set the session attribute. I would recommend that you create a bug in the MyFaces issue tracker. The problem is that MyFaces 1.2.x hasn't been updated in about a year and may no longer be worked on.

When you get a chance, please download the latest MyFaces 2.1.x source code and see if it is still a problem. Let us know what you find -- thanks!

Having said that, upgrading to Facelets has many benefits, including avoiding this JSP-related bug in MyFaces.

[Adam Nowak, modifié il y a 10 années.]

Hi Neil,
First of all I want to thank you for your fast response.

After spending some more time in the problem analysis I figured out that something is wrong with our jsf custom components. When I have simplified jsp view in the jsp portlet to contains only standard components from f and h taglibs the view has been displayed correctly.

Now, when i have working example it will be much easier to make the portlet works in the final shape.

P.S. I don't argue about benefits of having facelets instead of jsp. In my case it is just a matter of effort of migration from jsp and jsf 1 custom components.

Best regards,
Adam.

[Neil Griffin, modifié il y a 10 années.]

OK sounds good. Hope you enjoy continued success!