Details
-
Type:
Bug
-
Status: Resolved (View Workflow)
-
Priority:
Major
-
Resolution: Done
-
Affects Version/s: 1.1.0.Final, 1.1.1.Final
-
Fix Version/s: 1.1.3.Final
-
Component/s: Conversations, Web Tier integration (JSF, JSP, EL and Servlet)
-
Labels:None
-
Environment:Glassfish 3.1 B43 updated with weld-1.1.1
-
Git Pull Request:
Description
It seems that org.jboss.weld.jsf.WeldPhaseListener fails to activate conversation context if a conversation is not found by the supplied conversation id. This problem is potentially related to SEAMCATCH-46,WELD-855.
JSR-299 6.7.4 Conversation context lifecycle has a requirement that 'If the propagated conversation cannot be restored, the container must associate the request with a new transient conversation and throw an exception of type javax.enterprise.context.NonexistentConversationException from the restore view phase of the JSF lifecycle.'. However, the implementation of org.jboss.weld.jsf.WeldPhaseListener.activateConversations fails to do that if a conversation is not found by the conversation id.
private void activateConversations(FacesContext facesContext)
|
{
|
ConversationContext conversationContext = instance().select(HttpConversationContext.class).get();
|
String cid = getConversationId(facesContext, conversationContext);
|
log.debug(RESUMING_CONVERSATION, cid);
|
if (cid != null && conversationContext.getConversation(cid) == null)
|
{
|
throw new NonexistentConversationException(NO_CONVERSATION_FOUND_TO_RESTORE, cid);
|
}
|
conversationContext.activate(cid);
|
}
|
Recovering from the exception becomes difficult since the context is not active. Typical symptom is 'java.lang.IllegalStateException: Unable to load current conversations from the associated request, something went badly wrong when associate() was called
at org.jboss.weld.context.AbstractConversationContext.getCurrentConversation(AbstractConversationContext.java:413)'
Gliffy Diagrams
Activity
- All
- Comments
- Work Log
- History
- Activity
- Links Hierarchy
Still present in 1.1.1-Final.
Jarkko Hyöty
added a comment - Still present in 1.1.1-Final. This seems to be killing the viewAction from Seam Faces, preventing the viewAction component from performing navigations. Can we re-assess the priority of resolving this? Many eyes are looking at the viewAction right now, for possible inclusion in JSF 2.2.
I have a JSFUnit/Arquillian test in a feature branch of Seam Faces demonstrating this failure. Please let me know if you would like details on running this test (building JSFUnit is required at the moment).
Brian Leathem
added a comment - This seems to be killing the viewAction from Seam Faces, preventing the viewAction component from performing navigations. Can we re-assess the priority of resolving this? Many eyes are looking at the viewAction right now, for possible inclusion in JSF 2.2.
I have a JSFUnit/Arquillian test in a feature branch of Seam Faces demonstrating this failure. Please let me know if you would like details on running this test (building JSFUnit is required at the moment). Nevermind, Pete pointed out to me that the issue I am observing is most likely unrelated to this issuse. Apologies for the Jira SPAM 
Brian Leathem
added a comment - Nevermind, Pete pointed out to me that the issue I am observing is most likely unrelated to this issuse. Apologies for the Jira SPAM Still present in 1.1.2.Final (JBoss AS7). Also causes CDI TCK test failure in 1.1 branch.
Martin Kouba
added a comment - Still present in 1.1.2.Final (JBoss AS7). Also causes CDI TCK test failure in 1.1 branch. 
Hmm. Yes. I think we could get away with just calling conversationContext.activate() before throwing the exception since that is a passthrough to conversationContext.activate(null) which should use a temp BeanStore for the transient conversation.