You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by "Jose Luis Freire (JIRA)" <de...@myfaces.apache.org> on 2010/12/16 20:45:02 UTC
[jira] Created: (ORCHESTRA-55) Access Scoped Conversation is
incompatible with RichFaces 3.3.3
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.
[jira] Commented: (ORCHESTRA-55) Access Scoped Conversation is
incompatible with RichFaces 3.3.3
Posted by "Jose Luis Freire (JIRA)" <de...@myfaces.apache.org>.
[ 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.