[jira] [Resolved] (OWB-595) Use case "Faces Request Generates Non-Faces Response" locks conversation forever (-> BusyConversationException)

["Mark Struberg (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/OWB-595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mark Struberg resolved OWB-595.
-------------------------------

       Resolution: Fixed
    Fix Version/s: 1.1.1
         Assignee: Mark Struberg  (was: Gurkan Erdogdu)

fixed by closing/un-using the Conversation at the end of the Request if it exists

> Use case "Faces Request Generates Non-Faces Response" locks conversation forever (-> BusyConversationException)
> ---------------------------------------------------------------------------------------------------------------
>
>                 Key: OWB-595
>                 URL: https://issues.apache.org/jira/browse/OWB-595
>             Project: OpenWebBeans
>          Issue Type: Bug
>            Reporter: Martin Kočí
>            Assignee: Mark Struberg
>            Priority: Critical
>             Fix For: 1.1.1
>
>
> how to reproduce this issue:
> jsf2sample from OWB samples/conversation.jsf
> 1) modify ConversationData.getNumber to:         
> if (i == 11) { throw new NullPointerException(); } 
>  return i++;
> 2) click "Start conversation" (remember cid of newly created conversation, for example cid=2)
> 3) click "Show number" -> error page appears
> 4) create GET  request to new conversation = put in browser http://localhost:8080/jsf2sample/conversation.jsf?cid=2 where 2 is id of the new conversation -> BusyConversationException appears but conversation is not user by any thread!
> Reason: 
> OWB uses WebBeansPhaseListener fo managing conversation and set owbConversation.setInUsed(false) in after render response Phase. But render response phase is not mandatory:
> JSF 2.1 specification ,  2.1.3 Faces Request Generates Non-Faces Response:
> Normally, a JSF-based application will utilize the Render Response phase of the request processing lifecycle to actually
> create the response that is sent back to the client. In some circumstances, however, this behavior might not be desirable.
> For example:
> * A Faces Request needs to be redirected to a different web application resource (via a call to HttpServletResponse.sendRedirect).
> *  A Faces Request causes the generation of a response using some other technology (such as a servlet, or a JSP page not containing JSF components).
> *  Faces Request causes the generation of a response simply by serving up the bytes of a resource, such as an image, a JavaScript file, a CSS file, or an applet
> ... " It is then necessary to tell the JSF implementation that the response has already been created, so that the Render Response phase of the request processing lifecycle should ***BE SKIPPED***" ...
> Practical example from real world programming: file download - JSF library (trindiad, primefaces ,...) calls facesContext.responseComplete(); and therefore there will be no render response. If OWB conversationScoped bean is used here, then every next request to same conversation will obtain BusyConversationException.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira