[
https://issues.apache.org/jira/browse/OWB-595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13069799#comment-13069799
]
Joe Bergmark commented on OWB-595:
----------------------------------
As you pointed out, may be simple to just unlock the conversation at the end of
the request via our existing RequestListener. The only spec restriction
appears to be 2 requests operating on the same conversation. The key
conversation classes are visible from openwebbeans-impl, but maybe the risk is
creating a transient conversation just to immediately mark it as inactive if
the current request did not already have an active conversation.
> 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: Gurkan Erdogdu
> Priority: Critical
>
> 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
