[jira] Closed: (PLUTO-106) PortletServlet does not follow the servlet API

["David DeWolf (JIRA)" <pl...@jakarta.apache.org>]

     [ http://issues.apache.org/jira/browse/PLUTO-106?page=history ]
     
David DeWolf closed PLUTO-106:
------------------------------

    Resolution: Invalid

> PortletServlet does not follow the servlet API
> ----------------------------------------------
>
>          Key: PLUTO-106
>          URL: http://issues.apache.org/jira/browse/PLUTO-106
>      Project: Pluto
>         Type: Bug
>   Components: portlet container
>     Versions: 1.0.1-rc2
>  Environment: All
>     Reporter: Wayne Holder

>
> From inspection, it appears that PortletServlet is not thread safe and, in fact, is coded in a way that completely violates the requirements of the servlet life cycle.  As stated in SRV.2.2: "For a servlet not hosted in a distributed environment (the default), the servlet container must use only one instance per servlet declaration."  In practical terms, this means that one must not code a servlet in a way that assumes instance variables can be used to pass information from one method to another because multiple threads from simultaneous requests will overwrite each other's data, resulting in erratic behavior.  Yet, that's exactly how PortletServlet is coded.  In particular, the class declares tbese instance variables:
>   private boolean           portletInitialized = false;
>   private Portlet           portletClass = null;
> and then assumes it can set them in the init(ServletConfig) and that they will stay valid until PortletServlet's dispatch() method is called.  While this may appear to work in cases where only simple tests are being run, it's not correct and will act in unpredictable ways under real-world conditions.
> The cheap way out of this gotcha is to change the declaration of PortletServlet to implement the SingleThreadModel interface, as this will force the servlet container to guarantee that only one thread calls PortletServlet at any given time.  Of course, this is a kludge, and should be avoided from a performance standpoint, but it's at least avoid the potential twilight zone behavior of the current code.

-- 
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