Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 5.3

...

John A. Lewis
Unicon, Inc.

Introduction

Excerpt

JSR-168 Portlet applications represent a special challenge when it comes to clustering within Tomcat (or any other servlet container, for that matter). In order to effectively cluster web applications, session data must be replicated or shared between the nodes in the cluster. Otherwise, the user experiences a complete loss of context during a node failover. While Tomcat has provided session replication for quite some time, it has not supported replication of session changes resulting from a cross-context call from one webapp to another.

Portlets that are deployed as separate webapps from the portal webapp must be accessed by cross-context calls from the portal. This cross-context access creates a number of issues: servlet filters are not applied, session sharing between servlets and portlets is difficult, and session replication in Tomcat did not work.

At The University of Wisconsin-Madison (www.wisc.edu) and Pearson Education (www.pearsoned.com) both recently identified a need for full support of portlet session replication within Tomcat. They engaged with Unicon (www.unicon.net) , weto work with the Tomcat community to provide this capability. We've recently worked directly with the Tomcat developers to get Cross-Context Session Replication built into Tomcat 5.5 and we've demonstrated that portlet session data can now be properly replicated. I'd like to give a special thanks to Peter Rossbach from the Tomcat team for working on this with us and for getting this done so quickly. The changes for Tomcat are currently in the latest development codebase and will be included in version 5.5.16 and later.

...

Add the following <servlet> entries after the existing ones:

Code Block

   
<servlet>
        <servlet-name>TestPortlet1</servlet-name>
        <servlet-class>org.apache.pluto.core.PortletServlet</servlet-class>
        <init-param>
            <param<param-name>portlet-class</param-name>

           <param-value>org.apache.pluto.portalImpl.portlet.TestPortlet</param-value>
        </init-param>
        <init-param>

           <param-name>portlet-guid</param-name>
            <param-value>testsuite.TestPortlet1</param-value>
   
    </init-param>
        <security-role-ref>
            <role-name>plutoTestRole</role-name>
            <role-link>tomcat</role-link>
        </security-role-ref>
 
  </servlet>

    <servlet>
  
     <servlet-name>TestPortlet2</servlet-name>
        <servlet-class>org.apache.pluto.core.PortletServlet</servlet-class>
   
    <init-param>
            <param-name>portlet-class</param-name>
            <param-value>org.apache.pluto.portalImpl.portlet.TestPortlet</param-value>
        </init-param>
        <init-param>
 
          <param-name>portlet-guid</param-name>
            <param-value>testsuite.TestPortlet2</param-value>
  
     </init-param>
        <security-role-ref>
   
        <role-name>plutoTestRole</role-name>
            <role-link>tomcat</role-link>
   
    </security-role-ref>

   </servlet>

And then add the following <servlet-mapping> entries after the existing ones:

Code Block
    <servlet-mapping>
 
      <servlet-name>TestPortlet1</servlet-name>
        <url-pattern>/TestPortlet1/*</url-pattern>
  
 </servlet-mapping>

    <servlet-mapping>
   
    <servlet-name>TestPortlet2</servlet-name>
        <url-pattern>/TestPortlet2/*</url-pattern>
   
</servlet-mapping>

At this point you should be able to start the tomcatA instance and connect to http://localhost:8081/pluto/portal/ and see the portal and try out the test suite portlets. Do not proceed until this is all working correctly.

...