Liferay offers the possibility, to run a liferay servlet in the context of another web application. The class PortalServletWrapper does this trick. It is used for example by tunnel-web or cms-web.

Sometimes it is desirable to do the same trick the other way round: to let a custom servlet run in the context of the ROOT application. This allows for example the access to the same session. In fact, all custom portlets that are hot deployed into th eportal server are running in that way and can thus use some session attribute from the portal server (at least, if private-session-attributes is set to false in liferay-portal.xml).

I have created the classes PortalServletDelegationManager and PortalDelegateServlet to do that trick for servlets as well. The manager class will be running as servlet in the ROOT context. Its only purpose is to delegate matching requests to another servlet that is running in another context. In that servlet, getSession can be used to retrieve the session that is used by Liferay as well. It is important to put both classes into a place, where both the ROOT context and the application context uses the same instance (with respect to the classloader), because a static map is used. One such place is the common/classes folder of tomcat.

Both classes can be found in the attached archive.

The first class has to be configured in the web.xml of the ROOT application as servlet that listens for some context path (i.e. "delegate").
  <servlet>
    <servlet-name>DelegationManagerServlet</servlet-name>
    <servlet-class>de.hansemerkur.liferay.portal.servlet.PortalServletDelegationManager</servlet-class>
    <load-on-startup>0</load-on-startup>
  </servlet>
  <servlet-mapping>
    <servlet-name>DelegationManagerServlet</servlet-name>
    <url-pattern>/delegate/*</url-pattern>
  </servlet-mapping>

The second class has to be configured as servlet in the web.xml of some hot deploy portlet/servlet application. Two parameters are used to configure the delegation servlet: the first one defines the servlet class to that requests are delegated. The second (optional) parameter defines the sub context path for the delegation. If the second parameter is missing, the servlet name is used instead. In the given example, all requests to "/delegate/cognos" are delegated to the configured CognosServlet.
  <servlet>
    <servlet-name>cognos</servlet-name>
    <servlet-class>de.hansemerkur.liferay.portal.servlet.PortalDelegateServlet</servlet-class>
    <init-param>
      <param-name>servlet-class</param-name>
      <param-value>de.hansemerkur.mis2.report.servlet.CognosServlet</param-value>
    </init-param>
    <init-param>
      <param-name>sub-context</param-name>
      <param-value>cognos</param-value>
    </init-param>
    <load-on-startup>0</load-on-startup>
  </servlet>