[ http://issues.apache.org/struts/browse/SHALE-278?page=comments#action_38233 ] Scott Anderson commented on SHALE-278: --------------------------------------
This issue was originally added as a result of my attempt to create a portlet from the Blank Shale starter application using the jsf-bridge from the Bridges subproject of the Apache Portals project. The problem I encountered was that the jsf-bridge solution is incompatible with the use of Servlet filters. I was able to patch this problem with the creation of a PortletFilter implementation from the Bridges subproject which subclassed the ShaleApplicationFilter. Unfortunately, once this problem was overcome another more serious problem related to how the jsf-bridge mapped a portlet's action and render requests to the JSF Lifecycle's execute and render methods. The result was that the JSF view did not get setup correctly for portlet render requests unless they were immediately preceeded by portlet action requests. This is not enforceable. As I investigated this new problem further I discovered that the jsf-bridge project had in effect been obsoleted by the more recent support for portlets within MyFaces. Supposedly, similar support has been added to Sun's JSF RI also precluding the need for a JSF "portlet bridge". From what I have read and sensed, I am not confident that the jsf-bridge problem(s) will be fixed or that the jsf-bridge will continue to be supported. I was able to verify that converting the Shale Blank starter application to use the MyFacesGenericPortlet is straight forward and the result is compatible with current builds of Pluto, MyFaces, and Shale. Here is what is required ... 1) Follow instructions from the MyFaces wiki (http://wiki.apache.org/myfaces/CreatingJSFPortlets) to create a portlet application descriptor for Shale Blank (WEB-INF/portlet.xml) and set default-view to welcome.jsp. 2) remove the html, head, and body elements from welcome.jsp 3) In Shale Blank's web.xml add the following support for a pluto portlet servlet ... <servlet> <servlet-name>blank</servlet-name> <servlet-class>org.apache.pluto.core.PortletServlet</servlet-class> <init-param> <param-name>portlet-name</param-name> <param-value>blank</param-value> </init-param> <load-on-startup>1</load-on-startup> </servlet> [...] <servlet-mapping> <servlet-name>blank</servlet-name> <url-pattern>/PlutoInvoker/blank</url-pattern> </servlet-mapping> 4) In the Pluto Portal web application's portal driver config file (WEB-INF/pluto-portal-driver-config.xml) add the following support for declaring a portlet-app and portal page for the Shale Blank portlet ... <portlet-app> <context-path>/portlets</context-path> <portlets> <portlet name="blank"/> </portlets> </portlet-app> [...] <render-config> [...] <page name="Blank" uri="/WEB-INF/themes/pluto-default-theme.jsp"> <portlet context="/portlets" name="blank"/> </page> [...] </render-config> 5) Deploy the Pluto Portal war to context /pluto and the Shale Blank war to context /portlets. If you access the /pluto context you should be able to navigate to the Blank portal page containing a Shale Blank portlet. I believe the security for the Pluto Portal war is setup to be compatible with a default Tomcat install. > Create a shale-blank portlet project to prove that Shale works with portlets > ---------------------------------------------------------------------------- > > Key: SHALE-278 > URL: http://issues.apache.org/struts/browse/SHALE-278 > Project: Shale > Issue Type: New Feature > Components: Core > Reporter: Craig McClanahan > > The shale-blank sample application demonstrates (among other things) that the > core Shale infrastructure can work with a servlet container. We need a > similar application for a portlet container ... because anything in Shale > that has servlet API dependencies (such as the application controller > servlet) will not work. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
