Recently we’ve received a new request by our client to implement a Liferay Portlet that uses JPA as a primary ORM-system. Sure, Liferay provides Service Builders that enable ORM functionality in portlets, but I was always wondering why some companies prefer to develop their own frameworks instead of using already existing good solutions. So in this task we had to move from Liferay ORM + Liferay Transactions to well known and mature frameworks: Java JPA + Spring.

First of all we need to clarify some terms:

Servlet – is a Java implementation to support HTTP request/response protocol. So every servlet includes some code to handle client requests (POST/GET/…) and usually maintained by a servlet container (Tomcat, JBoss,…).

Portlets – are pluggable managed my portal web applications that define user interface look. These can be observed as small applications (email, user management, calendar) combined in a single portal view. Portals like servlets handle requests/responses, but in contrast to servlets portlets support only 3 request types: action, resource, render.

Spring Web MVC – is the implementation of Model-View-Controller pattern, build around Spring’s DispatcherServlet, where Controller is a Java Old Plain Object (POJO) that maps request urls to corresponding methods. The concept of Spring MVC is the same as in Servlets (handle HTTP requests), and Servlets can be substituted by Spring MVC providing easier setup and reducing development time. POJO Controller example:

@Controller
public class HelloWorldController {

    @RequestMapping("/helloWorld")
    public String helloWorld(Model model) {
        model.addAttribute("message", "Hello World!");
        return "helloWorld";
    }
}

Spring Portlet MVC - developed to support Portlet specification (JSR-168), the concepts of it are the same as in Spring Web MVC with differences created by the unique workflow of portlets.

The main way in which portlet workflow differs from servlet workflow is that the request to the portlet can have two distinct phases: the action phase and the render phase. The action phase is executed only once and is where any 'backend' changes or actions occur, such as making changes in a database. The render phase then produces what is displayed to the user each time the display is refreshed.

Like in ordinary portlets, the DispatcherPortlet should be declared in the portlet.xml of the web application:

<portlet>
    <portlet-name>sample</portlet-name>
    <portlet-class>org.springframework.web.portlet.DispatcherPortlet</portlet-class>
    <supports>
        <mime-type>text/html</mime-type>
        <portlet-mode>view</portlet-mode>
    </supports>
    <portlet-info>
        <title>Sample Portlet</title>
    </portlet-info>
</portlet>

The rendering in Portlet MVC is an extension of Spring Web MVC that reuses all view abilities of Spring. This rendering converts Portlet Requests/Responses to HttpServletRequests/Responses and then calls the render() method of the View interface. To make this work, DispatcherPortlet should use a ViewRendererServlet which must be declared in web.xml. Here is the final web.xml file for given application that will have only 2 entries: 

<servlet>
    <servlet-name>ViewRendererServlet</servlet-name>
    <servlet-class>org.springframework.web.servlet.ViewRendererServlet</servlet-class>
</servlet>

<servlet-mapping>
    <servlet-name>ViewRendererServlet</servlet-name>
    <url-pattern>/WEB-INF/servlet/view</url-pattern>
</servlet-mapping>

As we can see from the upper snippet – ViewRendererServlet mapped to /WEB-INF/servlet/view URL. One more thing we should add to use Spring view rendering mechanism is to define a PortletModeHandlerMapping, which will bind incoming requests based on the current mode of the portlet (“view”, “edit”, “help”). Here is spring context file snippet:

<bean id="portletModeHandlerMapping"
    class="org.springframework.web.portlet.handler.PortletModeHandlerMapping">
    <property name="portletModeMap">
        <map>
            <entry key="view">
                <ref bean="requestController" />
            </entry>
        </map>
    </property>     
</bean>

Request controller for Portlet MVC must implement *.portlet.mvc.Controller interface and appropriate to Portlet workflow methods handleActionRequest(), handleRenderRequest():

public interface Controller {

    ModelAndView handleRenderRequest(RenderRequest request, RenderResponse response)
        throws Exception;

    void handleActionRequest(ActionRequest request, ActionResponse response)
        throws Exception;

}

As mentioned before, Portlet MVC uses all Spring view functions, that allows us to inject ViewResolver implementation to current portlet. There are different out-of-the-box ViewResolver can be used (JSP, Freemarker, Velocity), we will use JSP resolver that is also defined in spring context file:

<bean id="viewResolver"
    class="org.springframework.web.servlet.view.InternalResourceViewResolver">
    <property name="viewClass"
        value="org.springframework.web.servlet.view.InternalResourceView" />
    <property name="prefix" value="/" />
    <property name="suffix" value=".jsp" />
</bean>

In order not to mess up the Portlet configuration with the Maven definitions I put maven dependency list to the end of this article:

        <!-- Spring -->
        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring-webmvc</artifactId>
            <version>x.x.RELEASE</version>
        </dependency>
        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring-tx</artifactId>
            <version>x.x.RELEASE</version>
        </dependency>
        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring-orm</artifactId>
            <version>x.x.RELEASE</version>
        </dependency>       
        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring-webmvc-portlet</artifactId>
            <version>x.x.RELEASE</version>
        </dependency>   

Actually you will need spring-tx and spring-orm libraries for JPA implementation only, so you can omit these 2 dependencies.

At this point our Liferay Spring Portlet is ready. In next article I’ll show how to inject JPA to this portlet.