You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openwebbeans.apache.org by "Mark Struberg (JIRA)" <ji...@apache.org> on 2011/08/28 12:05:37 UTC
[jira] [Commented] (OWB-595) Use case "Faces Request Generates
Non-Faces Response" locks conversation forever (->
BusyConversationException)
[ https://issues.apache.org/jira/browse/OWB-595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13092439#comment-13092439 ]
Mark Struberg commented on OWB-595:
-----------------------------------
Martin, even in case of a redirect to a non-faces request, we should get the afterPhase(any) and the following condition should be met:
{noformat}
if (phaseEvent.getPhaseId().equals(PhaseId.RENDER_RESPONSE) ||
phaseEvent.getFacesContext().getResponseComplete())
{noformat}
> 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