[
https://issues.apache.org/jira/browse/ORCHESTRA-55?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12975265#action_12975265
]
Jose Luis Freire commented on ORCHESTRA-55:
-------------------------------------------
Ok... There's already a "ignoreViewIds" property, that combined with
ORCHESTRA-54 works around this issue.
I still believe that we can do it in a more elegant way. Maybe not using a JSF
PhaseListener to handle access scoped conversations, but working with
OrchestraServletFilter.
> Access Scoped Conversation is incompatible with RichFaces 3.3.3
> ---------------------------------------------------------------
>
> Key: ORCHESTRA-55
> URL: https://issues.apache.org/jira/browse/ORCHESTRA-55
> Project: MyFaces Orchestra
> Issue Type: Bug
> Components: Conversation
> Affects Versions: 1.4
> Environment: Orchestra 1.4
> JSF 1.2
> RichFaces 3.3.3
> Reporter: Jose Luis Freire
> Priority: Critical
>
> This one is pretty twisted...
> RichFaces Resource Filter handles resources by simulating a faces request
> (see
> http://anonsvn.jboss.org/repos/richfaces/tags/3.3.3.Final/framework/impl/src/main/java/org/ajax4jsf/resource/ResourceLifecycle.java).
> The Orchestra heuristics to evaluate the need to invalidate scoped
> conversations makes the following assumptions:
> 1) There is only one request per page, being the exception AJAX requests
> where the viewId doesn't change;
> 2) Rely on renderResponse to evaluate if we're processing a new page (one
> that isn't a postback),
> With technologies like RichFaces this isn't true.
> RichFaces prior to 3.3.3 had a bug that simulated all JSF phases, but now it
> only simulates phase 1 (RESTORE_VIEW) and phase 6 (RENDER_RESPONSE).
> They achieve this by calling FacesContext.renderResponse() that sets
> renderResponse to TRUE to bypass all intermediate phases (see line 137 of
> ResourceLifecycle.java)
> Before 3.3.3, the renderResponse flag was false when handling RichFaces
> resources, and the Access Scoped conversations weren't evaluated because the
> current view was always set as the old view in
> AccessScopePhaseListener.doAfterRestoreView, so in doAfterRenderResponse the
> (viewRoot != oldViewRoot) evaluation would never invalidate the conversations.
> Here is a log of the phases in a single request to page /security/login.xhtml:
> 2010-12-16 19:06:49,441 DEBUG [TP-Processor2] (c.v.w.PhaseListener:119) -
> before RESTORE_VIEW 1
> 2010-12-16 19:06:49,448 DEBUG [TP-Processor2] (c.v.w.PhaseListener:68) -
> after RESTORE_VIEW 1
> 2010-12-16 19:06:49,449 INFO [TP-Processor2] (c.v.w.PhaseListener:72) -
> ViewID: /security/login.xhtml
> 2010-12-16 19:06:49,449 DEBUG [TP-Processor2] (c.v.w.PhaseListener:119) -
> before APPLY_REQUEST_VALUES 2
> 2010-12-16 19:06:49,456 DEBUG [TP-Processor2] (c.v.w.PhaseListener:68) -
> after APPLY_REQUEST_VALUES 2
> 2010-12-16 19:06:49,457 DEBUG [TP-Processor2] (c.v.w.PhaseListener:119) -
> before PROCESS_VALIDATIONS 3
> 2010-12-16 19:06:49,465 DEBUG [TP-Processor2] (c.v.w.PhaseListener:68) -
> after PROCESS_VALIDATIONS 3
> 2010-12-16 19:06:49,466 DEBUG [TP-Processor2] (c.v.w.PhaseListener:119) -
> before UPDATE_MODEL_VALUES 4
> 2010-12-16 19:06:49,467 DEBUG [TP-Processor2] (c.v.w.PhaseListener:68) -
> after UPDATE_MODEL_VALUES 4
> 2010-12-16 19:06:49,467 DEBUG [TP-Processor2] (c.v.w.PhaseListener:119) -
> before INVOKE_APPLICATION 5
> 2010-12-16 19:06:52,414 DEBUG [TP-Processor2] (c.v.w.PhaseListener:68) -
> after INVOKE_APPLICATION 5
> 2010-12-16 19:06:52,415 DEBUG [TP-Processor2] (c.v.w.PhaseListener:119) -
> before RENDER_RESPONSE 6
> 2010-12-16 19:06:53,975 DEBUG [TP-Processor2] (c.v.w.PhaseListener:68) -
> after RENDER_RESPONSE 6
> 2010-12-16 19:06:54,067 DEBUG [TP-Processor2] (c.v.w.PhaseListener:119) -
> before RESTORE_VIEW 1
> 2010-12-16 19:06:54,068 DEBUG [TP-Processor2] (c.v.w.PhaseListener:68) -
> after RESTORE_VIEW 1
> 2010-12-16 19:06:54,068 INFO [TP-Processor2] (c.v.w.PhaseListener:72) -
> ViewID: /org/richfaces/renderkit/html/css/basic_classes.xcss
> 2010-12-16 19:06:54,069 DEBUG [TP-Processor2] (c.v.w.PhaseListener:119) -
> before RENDER_RESPONSE 6
> 2010-12-16 19:06:54,207 DEBUG [TP-Processor2] (c.v.w.PhaseListener:68) -
> after RENDER_RESPONSE 6
> 2010-12-16 19:06:54,212 DEBUG [TP-Processor3] (c.v.w.PhaseListener:119) -
> before RESTORE_VIEW 1
> 2010-12-16 19:06:54,212 DEBUG [TP-Processor3] (c.v.w.PhaseListener:68) -
> after RESTORE_VIEW 1
> 2010-12-16 19:06:54,212 INFO [TP-Processor3] (c.v.w.PhaseListener:72) -
> ViewID: /css/toolBar.xcss
> 2010-12-16 19:06:54,213 DEBUG [TP-Processor3] (c.v.w.PhaseListener:119) -
> before RENDER_RESPONSE 6
> 2010-12-16 19:06:54,218 DEBUG [TP-Processor3] (c.v.w.PhaseListener:68) -
> after RENDER_RESPONSE 6
> 2010-12-16 19:06:54,219 DEBUG [TP-Processor1] (c.v.w.PhaseListener:119) -
> before RESTORE_VIEW 1
> 2010-12-16 19:06:54,220 DEBUG [TP-Processor1] (c.v.w.PhaseListener:68) -
> after RESTORE_VIEW 1
> 2010-12-16 19:06:54,220 INFO [TP-Processor1] (c.v.w.PhaseListener:72) -
> ViewID: /org/richfaces/renderkit/html/css/extended_classes.xcss
> 2010-12-16 19:06:54,221 DEBUG [TP-Processor1] (c.v.w.PhaseListener:119) -
> before RENDER_RESPONSE 6
> 2010-12-16 19:06:54,283 DEBUG [TP-Processor1] (c.v.w.PhaseListener:68) -
> after RENDER_RESPONSE 6
> 2010-12-16 19:06:54,493 DEBUG [TP-Processor1] (c.v.w.PhaseListener:119) -
> before RESTORE_VIEW 1
> 2010-12-16 19:06:54,494 DEBUG [TP-Processor1] (c.v.w.PhaseListener:68) -
> after RESTORE_VIEW 1
> 2010-12-16 19:06:54,494 INFO [TP-Processor1] (c.v.w.PhaseListener:72) -
> ViewID: /org/richfaces/renderkit/html/css/modalPanel.xcss
> 2010-12-16 19:06:54,495 DEBUG [TP-Processor1] (c.v.w.PhaseListener:119) -
> before RENDER_RESPONSE 6
> 2010-12-16 19:06:54,505 DEBUG [TP-Processor1] (c.v.w.PhaseListener:68) -
> after RENDER_RESPONSE 6
> I don't know the best way to get around this, and my suggestion is an ugly
> hack for testing for specific signatures on the viewId to ignore, like if the
> viewId starts with "/org/richfaces", then we don't invalidate access scoped
> conversations.
> Maybe we could do it in some kind of configuration parameters (like a
> properties file), so that by default there's no exceptions, and we could add
> them case by case.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
