+

Search Tips   |   Advanced Search

Access the portlet session on the anonymous page


View some pointers on handling portlet sessions in situations where portlets are placed on pages that do not require authentication.

Administrators may place the portlet on a page that is presented to anonymous users (similar to the Welcome page provided by WebSphere Portal). By default, when a portlet is placed on a page that does not require authentication and no user is logged in, the portal server does track sessions across subsequent request to the server. Portlets should not create a session using the request.getSession(true) call in this case; this will result in WAS warning messages similar to:

In this case, a temporary session is created and the session information will be lost in the next request. To enable session tracking across requests for non-authenticated users, we can do so by setting the public.session parameter in the portal Navigator service configuration or by setting the com.ibm.portal.public.session container run time option in a JSR 286 portlet deployment descriptors. Note that this may result in significantly increased memory consumption. For details about the com.ibm.portal.public.session option and a code sample refer to the topic about Deployment descriptors, section about Container run time options. Instead of using these options, portlets that need to maintain interaction state even for non-authenticated users should use render parameters to keep this information instead of the portlet session, as recommended by the Java Portlet Specification.

The portlet may need to present the user with an appropriate message if it requires a valid portlet session to operate correctly.

For example:

   This content cannot be displayed until you log in.
   Please report this problem to the site administrator.

In addition, the administrator will need more helpful information that the portlet can provide in the portlet log:

   Unable to locate the portlet session.      This portlet requires a session to function.
   Move the portlet to an authenticated page or     turn on session tracking for anonymous users.

If the portlet does not require a session for critical operation, then perhaps any subfunctions within the portlet require the session can be suppressed to anonymous users. This should be evaluated for each individual portlet.

If request.getPortletSession() or request.getPortletSession(true) are called when the user is not logged in and WebSphere Portal is not configured to use a session for anonymous users, each request from each client creates an extraneous PortletSession object that is lost and consumes JVM memory. This causes more frequent JVM garbage collection and hurts overall WebSphere Portal performance.

In order for a portlet to function without a portlet session, add this line to the beginning of all portlet JSPs.

    <%@ page session="false" %>

Without this directive, the JSP page compiler generates code that accesses the session even if you don't use it in the JSP. We also cannot access any beans with scope set to session in any of the JSP pages as shown.

    <jsp:useBean ... scope="session" />

This creates sessions when you do not want them. Instead, determine whether the session exists, for example:

<%
   com.ibm.MyClassName theBeanId = null;
   PortletSession session = request.getPortletSession(false);
   if (session != null) {
      theBeanId = (com.ibm.MyClassName)session.getAttribute("theBeanId");
   }

   // later in the code always check to see if the bean exists before using it    
   if (theBeanId != null) {
      // use the bean
   }
%>


Parent: Portlet development reference
Related:
Markup guidelines
Build .ear and .war files
Deployment descriptors
IBM portlet DTD tag reference
JSP tags for standard portlets
JSP tags for IBM portlets
Handling and visibility of request parameters in portlets
Detailed descriptions of the Struts WML tags
Application extension registry