myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Luis Freire (JIRA)" <...@myfaces.apache.org>
Subject [jira] Commented: (ORCHESTRA-55) Access Scoped Conversation is incompatible with RichFaces 3.3.3
Date Mon, 27 Dec 2010 14:55:46 GMT

    [ 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.


Mime
View raw message