You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openwebbeans.apache.org by "Martin Kočí (JIRA)" <ji...@apache.org> on 2011/07/22 20:57:06 UTC
[jira] [Created] (OWB-595) Use case "Faces Request Generates
Non-Faces Response" locks conversation forever (->
BusyConversationException)
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
[jira] [Resolved] (OWB-595) Use case "Faces Request Generates
Non-Faces Response" locks conversation forever (->
BusyConversationException)
Posted by "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
[jira] [Commented] (OWB-595) Use case "Faces Request Generates
Non-Faces Response" locks conversation forever (->
BusyConversationException)
Posted by "Mark Struberg (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Commented] (OWB-595) Use case "Faces Request Generates
Non-Faces Response" locks conversation forever (->
BusyConversationException)
Posted by "Mark Struberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OWB-595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13069817#comment-13069817 ]
Mark Struberg commented on OWB-595:
-----------------------------------
Hi!
I think we can do it in our ServletRequestListener. The spec prohibits that the Conversation gets touched by 2 Requests in parallel anyway.
> 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
[jira] [Commented] (OWB-595) Use case "Faces Request Generates
Non-Faces Response" locks conversation forever (->
BusyConversationException)
Posted by "Mark Struberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OWB-595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13092486#comment-13092486 ]
Mark Struberg commented on OWB-595:
-----------------------------------
Oki, I found the problem: it seems that FacesContext#getResponseComplete() returns false even if the underlying phase execution threw an Exception.
I'll move all the conversation closing stuff to our WebContextsService.
> 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
[jira] [Commented] (OWB-595) Use case "Faces Request Generates
Non-Faces Response" locks conversation forever (->
BusyConversationException)
Posted by "Martin Kočí (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OWB-595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13069682#comment-13069682 ]
Martin Kočí commented on OWB-595:
---------------------------------
I already reported it once: OWB-467 but proposed solution used servlet filter.
Is org.apache.webbeans.servlet.WebBeansConfigurationListener more suitable place to unlock 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
[jira] [Commented] (OWB-595) Use case "Faces Request Generates
Non-Faces Response" locks conversation forever (->
BusyConversationException)
Posted by "Joe Bergmark (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Commented] (OWB-595) Use case "Faces Request Generates
Non-Faces Response" locks conversation forever (->
BusyConversationException)
Posted by "Mark Struberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OWB-595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13092475#comment-13092475 ]
Mark Struberg commented on OWB-595:
-----------------------------------
please note that currently the CDI-1.0 ConversationScope is indeed only bound to JSF requests!
This will get fixed in CDI-1.1: https://issues.jboss.org/browse/CDI-148
> 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
[jira] [Commented] (OWB-595) Use case "Faces Request Generates
Non-Faces Response" locks conversation forever (->
BusyConversationException)
Posted by "Mark Struberg (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OWB-595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13092456#comment-13092456 ]
Mark Struberg commented on OWB-595:
-----------------------------------
oki, the "or non-faces-request" phrase is of course an argument :)
> 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
[jira] [Commented] (OWB-595) Use case "Faces Request Generates
Non-Faces Response" locks conversation forever (->
BusyConversationException)
Posted by "Martin Kočí (JIRA)" <ji...@apache.org>.
[ 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