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.
