|
||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||
|
||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||
Now I'm 100% sure ConversationPropagationFilter needs to be made into a no-op.
The filter does way more that it is supposed to. In a standard JSF app without CDI/Weld, if you do a HttpServletResponse.sendRedirect("/viewid.xhtml"), the browser will be redirected to "/viewid.xhtml" (and not "/appcontext/viewid.faces"). However, if you do the same in a JSF+Weld app and the current request is associated with a long-running conversation, the filter will resolve the viewid and actually send a redirect to "/appcontext/viewid.faces". So, basically, instead of only adding the cid parameter, the filter completely changes the behaviour of JSF.
If we remove the viewId resolution part from the filter, the only thing that the filter will be doing, is appending the cid to the url. It shouldn't be doing this either, because according to the CDI spec, the cid should only be propagated for redirects resulting from a navigation rule or JSF NavigationHandler. And this is already taken care of by ConversationAwareViewHandler.
So, we need to make the filter a no-op (for those cases, where people have explicitly added the filter into web.xml) and remove the automatic registration of the filter from jboss-as-weld.