3:57 p.m.
WeldPhaseListener should only cleanup response once
---------------------------------------------------
Key: WELD-461
URL: https://jira.jboss.org/jira/browse/WELD-461
Project: Weld
Issue Type: Bug
Components: Web Tier integration (JSF, JSP, EL and Servlet)
Affects Versions: 1.0.1.Final
Reporter: Dan Allen
Priority: Minor
FacesContext#getResponseCompete() may be true on more than one invocation of
WeldPhaseListener#afterPhase(). Since the phase listener does not check to see if the
request has already been cleaned up, Weld fails on the second cleanup attempt.
How does this scenario happen? One case is when the application calls
ExternalContext#dispatch() to forward to another view. When the dispatch happens, the
current lifecycle is marked FacesContext#responseComplete(). Control turns over to the
lifecycle of the dispatched request. When the response is complete in that request, the
WeldPhaseListener#afterPhase() will be called with FacesContext#getResponseComplete()
equal to true. Control returns to the original request lifecycle,
WeldPhaseListener#afterPhase() will again be called with
FacesContext#getResponseComplete() equal to true.
The WeldPhaseListener should check to see if cleanup has already occurred, skipping
cleanup if it has.
Applications should not expect contexts to be active in the original request lifecycle
after ExternalContext#dispatch() has been called.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
11:18 p.m.
New subject: [JBoss JIRA] Commented: (WELD-461) WeldPhaseListener should only cleanup response once
[
https://jira.jboss.org/jira/browse/WELD-461?page=com.atlassian.jira.plugi...
]
Nicklas Karlsson commented on WELD-461:
---------------------------------------
What is the stack trace on failure? Is it from the conversation context being destroyed
twice and the BeanStore being null? One option would be to move the destruction flag into
the conversation manager and have it reset when the conversation is set up.
WeldPhaseListener should only cleanup response once
---------------------------------------------------
Key: WELD-461
URL: https://jira.jboss.org/jira/browse/WELD-461
Project: Weld
Issue Type: Bug
Components: Web Tier integration (JSF, JSP, EL and Servlet)
Affects Versions: 1.0.1.Final
Reporter: Dan Allen
Priority: Minor
FacesContext#getResponseCompete() may be true on more than one invocation of
WeldPhaseListener#afterPhase(). Since the phase listener does not check to see if the
request has already been cleaned up, Weld fails on the second cleanup attempt.
How does this scenario happen? One case is when the application calls
ExternalContext#dispatch() to forward to another view. When the dispatch happens, the
current lifecycle is marked FacesContext#responseComplete(). Control turns over to the
lifecycle of the dispatched request. When the response is complete in that request, the
WeldPhaseListener#afterPhase() will be called with FacesContext#getResponseComplete()
equal to true. Control returns to the original request lifecycle,
WeldPhaseListener#afterPhase() will again be called with
FacesContext#getResponseComplete() equal to true.
The WeldPhaseListener should check to see if cleanup has already occurred, skipping
cleanup if it has.
Applications should not expect contexts to be active in the original request lifecycle
after ExternalContext#dispatch() has been called.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
11:24 p.m.
New subject: [JBoss JIRA] Commented: (WELD-461) WeldPhaseListener should only cleanup response once
[
https://jira.jboss.org/jira/browse/WELD-461?page=com.atlassian.jira.plugi...
]
Dan Allen commented on WELD-461:
--------------------------------
Ah, right. A stacktrace would always help :)
SEVERE: javax.faces.FacesException: No bean store available for Active conversation
context
javax.faces.FacesException: No bean store available for Active conversation context
at
com.sun.faces.context.ExceptionHandlerImpl.handle(ExceptionHandlerImpl.java:136)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:119)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:312)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1523)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:279)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:188)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:641)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:97)
at
com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:85)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:185)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:332)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:233)
at
com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:165)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:791)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:693)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:954)
at
com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:170)
at
com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:135)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:102)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:88)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:76)
at
com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:53)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:57)
at com.sun.grizzly.ContextTask.run(ContextTask.java:69)
at
com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:330)
at
com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:309)
at java.lang.Thread.run(Thread.java:619)
Caused by: java.lang.IllegalStateException: No bean store available for Active
conversation context
at org.jboss.weld.context.AbstractMapContext.destroy(AbstractMapContext.java:155)
at
org.jboss.weld.context.AbstractThreadLocalMapContext.destroy(AbstractThreadLocalMapContext.java:68)
at
org.jboss.weld.conversation.AbstractConversationManager.cleanupConversation(AbstractConversationManager.java:179)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.jboss.weld.bean.proxy.ClientProxyMethodHandler.invoke(ClientProxyMethodHandler.java:113)
at
org.jboss.weld.conversation.ServletConversationManager_$$_javassist_14.cleanupConversation(ServletConversationManager_$$_javassist_14.java)
at
org.jboss.weld.jsf.WeldPhaseListener.afterResponseComplete(WeldPhaseListener.java:151)
at org.jboss.weld.jsf.WeldPhaseListener.afterPhase(WeldPhaseListener.java:108)
at com.sun.faces.lifecycle.Phase.handleAfterPhase(Phase.java:189)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:107)
... 26 more
WeldPhaseListener should only cleanup response once
---------------------------------------------------
Key: WELD-461
URL: https://jira.jboss.org/jira/browse/WELD-461
Project: Weld
Issue Type: Bug
Components: Web Tier integration (JSF, JSP, EL and Servlet)
Affects Versions: 1.0.1.Final
Reporter: Dan Allen
Priority: Minor
FacesContext#getResponseCompete() may be true on more than one invocation of
WeldPhaseListener#afterPhase(). Since the phase listener does not check to see if the
request has already been cleaned up, Weld fails on the second cleanup attempt.
How does this scenario happen? One case is when the application calls
ExternalContext#dispatch() to forward to another view. When the dispatch happens, the
current lifecycle is marked FacesContext#responseComplete(). Control turns over to the
lifecycle of the dispatched request. When the response is complete in that request, the
WeldPhaseListener#afterPhase() will be called with FacesContext#getResponseComplete()
equal to true. Control returns to the original request lifecycle,
WeldPhaseListener#afterPhase() will again be called with
FacesContext#getResponseComplete() equal to true.
The WeldPhaseListener should check to see if cleanup has already occurred, skipping
cleanup if it has.
Applications should not expect contexts to be active in the original request lifecycle
after ExternalContext#dispatch() has been called.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
1:23 p.m.
New subject: [JBoss JIRA] Updated: (WELD-461) WeldPhaseListener should only cleanup response once
[
https://jira.jboss.org/jira/browse/WELD-461?page=com.atlassian.jira.plugi...
]
Pete Muir updated WELD-461:
---------------------------
Fix Version/s: 1.0.2.CR1
WeldPhaseListener should only cleanup response once
---------------------------------------------------
Key: WELD-461
URL: https://jira.jboss.org/jira/browse/WELD-461
Project: Weld
Issue Type: Bug
Components: Web Tier integration (JSF, JSP, EL and Servlet)
Affects Versions: 1.0.1.Final
Reporter: Dan Allen
Priority: Minor
Fix For: 1.0.2.CR1
FacesContext#getResponseCompete() may be true on more than one invocation of
WeldPhaseListener#afterPhase(). Since the phase listener does not check to see if the
request has already been cleaned up, Weld fails on the second cleanup attempt.
How does this scenario happen? One case is when the application calls
ExternalContext#dispatch() to forward to another view. When the dispatch happens, the
current lifecycle is marked FacesContext#responseComplete(). Control turns over to the
lifecycle of the dispatched request. When the response is complete in that request, the
WeldPhaseListener#afterPhase() will be called with FacesContext#getResponseComplete()
equal to true. Control returns to the original request lifecycle,
WeldPhaseListener#afterPhase() will again be called with
FacesContext#getResponseComplete() equal to true.
The WeldPhaseListener should check to see if cleanup has already occurred, skipping
cleanup if it has.
Applications should not expect contexts to be active in the original request lifecycle
after ExternalContext#dispatch() has been called.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
9:13 a.m.
New subject: [JBoss JIRA] Assigned: (WELD-461) WeldPhaseListener should only cleanup response once
[
https://jira.jboss.org/jira/browse/WELD-461?page=com.atlassian.jira.plugi...
]
Nicklas Karlsson reassigned WELD-461:
-------------------------------------
Assignee: Nicklas Karlsson
WeldPhaseListener should only cleanup response once
---------------------------------------------------
Key: WELD-461
URL: https://jira.jboss.org/jira/browse/WELD-461
Project: Weld
Issue Type: Bug
Components: Web Tier integration (JSF, JSP, EL and Servlet)
Affects Versions: 1.0.1.Final
Reporter: Dan Allen
Assignee: Nicklas Karlsson
Priority: Minor
Fix For: 1.0.2.CR1
FacesContext#getResponseCompete() may be true on more than one invocation of
WeldPhaseListener#afterPhase(). Since the phase listener does not check to see if the
request has already been cleaned up, Weld fails on the second cleanup attempt.
How does this scenario happen? One case is when the application calls
ExternalContext#dispatch() to forward to another view. When the dispatch happens, the
current lifecycle is marked FacesContext#responseComplete(). Control turns over to the
lifecycle of the dispatched request. When the response is complete in that request, the
WeldPhaseListener#afterPhase() will be called with FacesContext#getResponseComplete()
equal to true. Control returns to the original request lifecycle,
WeldPhaseListener#afterPhase() will again be called with
FacesContext#getResponseComplete() equal to true.
The WeldPhaseListener should check to see if cleanup has already occurred, skipping
cleanup if it has.
Applications should not expect contexts to be active in the original request lifecycle
after ExternalContext#dispatch() has been called.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12:07 a.m.
New subject: [JBoss JIRA] Closed: (WELD-461) WeldPhaseListener should only cleanup response once
[
https://jira.jboss.org/jira/browse/WELD-461?page=com.atlassian.jira.plugi...
]
Nicklas Karlsson closed WELD-461.
---------------------------------
Resolution: Done
Closed by exiting early for all context destruction about to take place on a context with
a null BeanStore
Would a more correct place for this fix be in the Conversation Manager
or in the PhaseListener (how is it shared, can you keep a boolean flag there)?
WeldPhaseListener should only cleanup response once
---------------------------------------------------
Key: WELD-461
URL: https://jira.jboss.org/jira/browse/WELD-461
Project: Weld
Issue Type: Bug
Components: Web Tier integration (JSF, JSP, EL and Servlet)
Affects Versions: 1.0.1.Final
Reporter: Dan Allen
Assignee: Nicklas Karlsson
Priority: Minor
Fix For: 1.0.2.CR1
FacesContext#getResponseCompete() may be true on more than one invocation of
WeldPhaseListener#afterPhase(). Since the phase listener does not check to see if the
request has already been cleaned up, Weld fails on the second cleanup attempt.
How does this scenario happen? One case is when the application calls
ExternalContext#dispatch() to forward to another view. When the dispatch happens, the
current lifecycle is marked FacesContext#responseComplete(). Control turns over to the
lifecycle of the dispatched request. When the response is complete in that request, the
WeldPhaseListener#afterPhase() will be called with FacesContext#getResponseComplete()
equal to true. Control returns to the original request lifecycle,
WeldPhaseListener#afterPhase() will again be called with
FacesContext#getResponseComplete() equal to true.
The WeldPhaseListener should check to see if cleanup has already occurred, skipping
cleanup if it has.
Applications should not expect contexts to be active in the original request lifecycle
after ExternalContext#dispatch() has been called.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
7:15 p.m.
New subject: [JBoss JIRA] Commented: (WELD-461) WeldPhaseListener should only cleanup response once
[
https://jira.jboss.org/jira/browse/WELD-461?page=com.atlassian.jira.plugi...
]
Pete Muir commented on WELD-461:
--------------------------------
I think the phase listener is the correct place. I believe the instance is shared for the
whole application.
WeldPhaseListener should only cleanup response once
---------------------------------------------------
Key: WELD-461
URL: https://jira.jboss.org/jira/browse/WELD-461
Project: Weld
Issue Type: Bug
Components: Web Tier integration (JSF, JSP, EL and Servlet)
Affects Versions: 1.0.1.Final
Reporter: Dan Allen
Assignee: Nicklas Karlsson
Priority: Minor
Fix For: 1.0.2.CR1
FacesContext#getResponseCompete() may be true on more than one invocation of
WeldPhaseListener#afterPhase(). Since the phase listener does not check to see if the
request has already been cleaned up, Weld fails on the second cleanup attempt.
How does this scenario happen? One case is when the application calls
ExternalContext#dispatch() to forward to another view. When the dispatch happens, the
current lifecycle is marked FacesContext#responseComplete(). Control turns over to the
lifecycle of the dispatched request. When the response is complete in that request, the
WeldPhaseListener#afterPhase() will be called with FacesContext#getResponseComplete()
equal to true. Control returns to the original request lifecycle,
WeldPhaseListener#afterPhase() will again be called with
FacesContext#getResponseComplete() equal to true.
The WeldPhaseListener should check to see if cleanup has already occurred, skipping
cleanup if it has.
Applications should not expect contexts to be active in the original request lifecycle
after ExternalContext#dispatch() has been called.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
5155
days inactive
5187
days old
6 comments
3 participants
participants (3)
-
Dan Allen (JIRA) -
Nicklas Karlsson (JIRA)
-
Pete Muir (JIRA)