PortalDelegateServlet – Servlet Session Sharing in Liferay

After finishing my blog entry Liferay Session Sharing Demystified, i found a forum post which pointed to the liferay Jira of LEP-2297. Turns out Liferay 4.3.x has built in support for running servlets from within the Portal context! Yes... yet another wonderful but undocumented feature in Liferay.

In a nutshell, you configure your servlet to register itself with the built in PortalDelegatorServlet. This servlet (in the portal’s context) makes a cross-context call to your servlet, and provides your servlet with the portal session.

From a session sharing point of view, this behaves exactly the same as portlets using the portal session (i.e. portlets set to non-private session)

• full access to portal attributes
• full access to non-private portlet attributes, regardless of WAR file
• Shared attributes set by the servlet will be made visible to the private portlets
• no access to the WAR session attributes (servlets and private portlets in the same war)

Configuration Example

The example configuration in the Jira is based on the code that was submitted, so here is an example based on the Liferay’s distribution. In your servlet’s web.xml file, configure the following servlet.

<servlet>
  <servlet-name>springdemo</servlet-name>
  <servlet-class>
    com.liferay.portal.kernel.servlet.PortalDelegateServlet
  </servlet-class>
  <init-param>
    <param-name>servlet-class</param-name>
    <param-value>
      org.springframework.web.servlet.DispatcherServlet
    </param-value>
  </init-param>
  <init-param>
    <param-name>sub-context</param-name>
    <param-value>downloads</param-value>
  </init-param>
  <load-on-startup>1</load-on-startup>
</servlet>

This example registers your servlet example.FooServlet under the key foo.do. (If a sub-context is not provided, the servlet-name will be used as the key instead.) When a request is made to /delegate/foo.do , the PortalDelegateServlet will process the URL, lookup the key foo.do, find your servlet, and make a cross context call to your servlet to run the service method. If you don’t like the /delegate servlet-mapping, you can change this in the portal’s ROOT.war web.xml.

Limitation

One confusing thing is that the sub-context is used as the key to store the servlet, while only the first token of the URI is used as the key to lookup the servlet. Which means if you try to set the sub-context to myapp/foo.do then navigate to the URI of /delegate/myapp/foo.do , it won’t work, because the PortalDelegateServlet will attempt to lookup the map using the value myapp, and find nothing. Bottom line: the sub-context must be only single level deep.

Using Spring DispatcherServlet

If you use Spring as your front-controller, you can configure more sophisticated URLs. The DispatcherServlet can be configured for use with the PortalDelegateServlet as follows:

<servlet>
  <servlet-name>springdemo</servlet-name>
  <servlet-class>
    com.liferay.portal.kernel.servlet.PortalDelegateServlet
  </servlet-class>
  <init-param>
    <param-name>servlet-class</param-name>
    <param-value>
   org.springframework.web.servlet.DispatcherServlet
 </param-value>
  </init-param>
  <init-param>
    <param-name>sub-context</param-name>
    <param-value>downloads</param-value>
  </init-param>
  <load-on-startup>1</load-on-startup>
</servlet>

Then in the springdemo-servlet.xml, you will have something like this, to configure a mapping to the URL of /delegate/downloads/getdocument.do

<bean id="myDownloadController" class="example.SpringServletController" />
<bean id="urlMapping" 
    class="org.springframework.web.servlet.handler.SimpleUrlHandlerMapping">
  <property name="mappings">
    <props>
      <prop key="/downloads/getdocument.do">myDownloadController</prop>  
    </props>
  </property>
</bean>

Caveats

You will need to be careful if you are using third party libraries like Spring. These libraries don’t expect you to be invoking a cross context call, so anything can happen!

For example, when wiring up the Spring DispatcherServlet, writing directly to the response output was fine, but returning a ModelAndView didn’t work. Further investigation revealed that InternalResourceViewResolver was looking in ROOT.war to resolve the location of the view. Which means if the prefix was /WEB-INF/jsp/ , you would have to put this inside /ROOT.war/WEB-INF/jsp , which is clearly not workable.

However, servlets are usually deployed in the portal is to enable some sort of file download, which requires you to write directly to the response output stream anyway, and for this use case the PortalDelegateServlet is the perfect tool.