You are viewing a plain text version of this content. The canonical link for it is here.
Posted to pluto-dev@portals.apache.org by pl...@jakarta.apache.org on 2004/10/14 15:28:51 UTC

[jira] Resolved: (PLUTO-68) Pluto violates Specification Section PLT.15.2

Message:

   The following issue has been resolved as INVALID.

   Resolver: David DeWolf
       Date: Thu, 14 Oct 2004 6:28 AM

Just because the same id is being used, doesn't mean that the sessions themselves are identical.  Pluto leverages the HttpSession for it's PortletSession functionality.  Because HttpSessions are (per spec) also scoped at the context level, when executing in any valid servlet container the PortletSession will automatically be unique per portlet application.

Further more, the servlet spec seems to encourage the reuse of the mechanism used to establish the session.  7.3 of the spec states:

===== Begin 7.3 Servlet Spec ====
HttpSession objects must be scoped at the application (or servlet context) level. The underlying mechanism, such as the cookie used to establish the session, can be the same for different contexts, but the object referenced, including the attributes in that object, must never be shared between contexts by the container. To illustrate this requirement with an example: if a servlet uses the RequestDispatcher to call a servlet in another web application, any sessions created for and visible to the callee servlet must be different from those visible to the calling servlet.
===== End 7.3 Servlet Spec =====

Because of this, you will find that in Tomcat for instance, it is the combination of the context path AND the session id that defines a unique session.
---------------------------------------------------------------------
View the issue:
  http://issues.apache.org/jira/browse/PLUTO-68

Here is an overview of the issue:
---------------------------------------------------------------------
        Key: PLUTO-68
    Summary: Pluto violates Specification Section PLT.15.2
       Type: Bug

     Status: Resolved
   Priority: Blocker
 Resolution: INVALID

    Project: Pluto
 Components: 
             portlet container
   Versions:
             Current CVS

   Assignee: 
   Reporter: Daniel Grob

    Created: Thu, 30 Sep 2004 7:28 AM
    Updated: Thu, 14 Oct 2004 6:28 AM
Environment: Tomcat 4.1.29, Windows XP SP2, JRE 1.4.2_05

Description:
Specification Section PLT.15.2 states:
"PortletSession objects must be scoped at the portlet application context level. Each portlet application has its own distinct PortletSession object per user session. The portlet container must not share the PortletSession object or the attributes stored
in it among different portlet applications or among different user sessions."

Pluto seems not to comply with this section. When deploying two portlet applications (e.g. using the Pluto Deploy class) that both just display the current portlet session id and running them, both portlets display the identical session id.


---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira