Details
-
Bug
-
Status: Closed
-
Critical
-
Resolution: Fixed
-
None
-
None
-
None
Description
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.