<servlet>
<!-- Should always match the portlet-name in portlet.xml -->
<servlet-name>504</servlet-name>
<!-- Should always be this class -->
<servlet-class>com.liferay.portal.kernel.servlet.PortletServlet</servlet-class>
<!-- Add an init param that specifies our portlet class, same as portlet-class from portlet.xml -->
<init-param>
<param-name>portlet-class</param-name>
<param-value>com.tbbgl.portlet.TbbglGenericPortlet</param-value>
</init-param>
<load-on-startup>0</load-on-startup>
</servlet>
<!--
Mapping for the portlet servlet. -->
<servlet-mapping>
<servlet-name>504</servlet-name>
<url-pattern>/504/*</url-pattern>
</servlet-mapping>
Note that the portlet class really extends from the org.apache.myfaces.portlet.MyFacesGenericPortlet. The servlet name is a little ambiguous, but we decided we were going to follow Liferay's portlet naming scheme (internally all of their portlets are numbered).
The important part to follow is your portal provider's doco regarding the servlet requirements.
2. In faces-config.xml you'll probably need a customized context factory which (hopefully) your portal provider gives you. In Liferay we use:
<factory><!-- This is used to construct the faces context for an incoming HttpServletRequest/Response pair. -->
<faces-context-factory>com.liferay.util.jsf.apache.myfaces.context.MyFacesContextFactoryImpl</faces-context-factory>
</factory>
Other than that there were minor changes that we made to our application such as the removal of the tags prior to and including the <body> tag (as well as their closing tags) since they are not necessary (although the portal should gracefully strip these w/o the changes).
Otherwise you should find that your application works quite well under the jsr-168 framework. If you're using filters of any kind (i.e. acegi security filters, hibernate filters, etc.), this is where you're going to be in dark territories. jsr-168 does not support filters (jsr-268 is supposed to support filters, but I don't know what the ETA is for the jsr release nor how long it will take the portal vendors to include support).
In our environment we used the MyFacesGenericPortlet extension class as an entry point to handle filters, although we had to re-write the filters to work using the portlet's request/response objects over ServetRequest/ServletResponse. This effort is not related to JSF per se, but it will be an issue in migrating to JSR-168 that you should be aware of.
-----Original Message-----Hi
From: Laurentiu Trica [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 31, 2006 7:19 AM
To: [email protected]
Subject: Creating portlets from an existing JSF web application
Does anyone know a good place for such a documentation?
Thanks a lot.
--
Best regards,
Laurentiu
