[
https://issues.apache.org/jira/browse/OWB-595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13092451#comment-13092451
]
Martin Kočí commented on OWB-595:
---------------------------------
That should work, because after phase events are delivered. It seems that this
can solve this partikular problem for OWB 1.1.1.
But I'm not sure if there are any others conditions that can break JSF
lifecycle ( for example bug in mojarra :) ) causing immediate lifecycle exit
and without afterPhase event delivery.
And: is conversation scope JSF-only? CDI spec 6.7.4. Conversation context
lifecycle "Conversation scope is active during all standard lifecycle phases of
any JSF faces OR NON-FACES REQUEST".
> 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
