[jira] [Commented] (ORCHESTRA-65) Create artifacts compatible with JSF 2.2

["Leonardo Uribe (JIRA)" <de...@myfaces.apache.org>]

    [ https://issues.apache.org/jira/browse/ORCHESTRA-65?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13965414#comment-13965414 ] 

Leonardo Uribe commented on ORCHESTRA-65:
-----------------------------------------

I have been thinking about this and doing some tests about what can we
do to update the code. Basically we have these options:

1. Make Orchestra use JSF 2.2 client window id if JSF is available. If 
not fallback to the default.

2. Make JSF use Orchestra conversationContext id as client window id.

3. If JSF 2.2 is available, associate the conversationContext with the 
current client window id and store it into session.

OPTION 1:

The problem with option 1 is that Orchestra has its own logic related
to conversationContext and its own tags. In Orchestra, it is possible
to activate a conversationContext, or create a new one on the way, but
the idea about the client window is manage that in the server or in
the client, so that logic just doesn't fit well because the client
window id has a different meaning, but it is related with the 
conversation context, because it is not possible to have the same
conversation context across different windows. 

The base documentation say this:

http://myfaces.apache.org/orchestra/multiwindow.html

"... Therefore the concept of state management is core; the 
"ConversationContext" class holds the entire set of active conversations and 
a user can have multiple ConversationContext objects (although only one is 
used for any particular http request). Providing per-window state management 
is just a matter of associating a window with a particular 
ConversationContext. ..."

It also says this:

"... There is also one Orchestra-specific issue related to multiple windows: 
the "access-scope conversation" feature fails when multiple windows are 
sharing the same state. Access scope monitors requests and automatically 
cleans up conversations that are no longer being used. However when two 
windows are accessing the same orchestra-enabled webapp concurrently and 
use the same per-window-state, then a request in one window would cause 
conversations to be discarded which the other window later wants to use. ..."

If there is an active conversational context in one window and that one
ends and a new one is activated on the same request, it is clear the
client window id doesn't change, but the conversational context changes.
So, in that sense option 1 can theoretically be done, but the cost is
orchestra lose control over the conversational context id, and there 
is already some logic in place behind it, so with option 1 we are just
breaking that part that still has sense in Orchestra API.

OPTION 2:

The problem with option 2 is you lose the pluggability that JSF 2.2 
provides, so it is pointless. Orchestra 2.0 is already compatible with
JSF 2.2, so it is an option but that's not what we want.

OPTION 3:

The problem with option 3 is precisely its virtue: it makes a clear 
distinction between the client window and the conversation context id.
But the conversationContext is not as a query parameter anymore. Yes,
that's what we really want, get rid of it to put something better
and more pluggable in place, but if you are in JSF and there is 
a query to some other place and you want to keep the conversation,
you need to add it manually. In those cases a call to:

    url = RequestParameterProviderManager.getInstance().encodeAndAttachParameters(url);
	
will do the job, it is not the most nice thing you can do, but most of 
the time you don't go as far. I mean, you can always fallback to the 
conversationContext param. Not a big deal.

The big advantage of option 3 is that keeps the pluggable model of
JSF 2.2 client window. So, you can provide alternate implementations and
all of them will work with MyFaces Orchestra, which is something nice.


If no objections I'll proceed to apply option 3 into MyFaces Orchestra.

> Create artifacts compatible with JSF 2.2
> ----------------------------------------
>
>                 Key: ORCHESTRA-65
>                 URL: https://issues.apache.org/jira/browse/ORCHESTRA-65
>             Project: MyFaces Orchestra
>          Issue Type: Task
>            Reporter: Leonardo Uribe
>            Assignee: Leonardo Uribe
>
> In JSF 2.2 it was included a solution for manage client windows logic and state. It was inspired in MyFaces Orchestra, but as a side effect now the artifacts for JSF 2.0 are no longer compatible with 2.2, because they overlap the same logic. MyFaces Orchestra used a request parameter called "conversationId" but now jsf defined a new param for that.
> Additionally, MyFaces Orchestra can be a good place to provide custom implementations for some features that depends on MyFaces Core SPI interface like:
> - Spring variant of ViewScope
> - Spring variant of FlowScope
> Since there are some important changes, the idea is do not follow the strategy used in jsf 2.0 (use myfaces builder plugin unpack goal) and copy the files in a new module.



--
This message was sent by Atlassian JIRA
(v6.2#6252)