You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by "Gabrielle Crawford (JIRA)" <de...@myfaces.apache.org> on 2009/11/18 23:48:39 UTC
[jira] Created: (TRINIDAD-1642) Trinidad 2 - server side state
saving does not work
Trinidad 2 - server side state saving does not work
---------------------------------------------------
Key: TRINIDAD-1642
URL: https://issues.apache.org/jira/browse/TRINIDAD-1642
Project: MyFaces Trinidad
Issue Type: Bug
Reporter: Gabrielle Crawford
Server side state saving is not working in Trinidad 2.0, instead of writing a token to the client the full state is written to the client.
In Trinidad we have
* our own stateManager which wraps the RI's state manager.
* our own responseStateManager which does not wrap the RI's state manager
For server side state saving we delegate to the RI's state manager. In JSF 1.2 the RI's stateManager handled saving the state on the session for server side state saving. So server side state saving worked in Trinidad 1.2.
In JSF 2.0 the StateManager no longer handles server side state saving, now the ResponseStateManager handles server side state saving. Trinidad's CoreResponseStateManager just writes out whatever state it was given, so it writes out the full state instead of writing out a token and saving the state in the session.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1642) Trinidad 2 - server side state
saving does not work
Posted by "Gabrielle Crawford (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/TRINIDAD-1642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12786074#action_12786074 ]
Gabrielle Crawford commented on TRINIDAD-1642:
----------------------------------------------
In JSF 1.2 things worked like this in trinidad
1] javax.faces.STATE_SAVING_METHOD = server, then you're using the JSF RI server side state saving. This does not work correctly with multiple windows.
2] javax.faces.STATE_SAVING_METHOD = client and org.apache.myfaces.trinidad.CLIENT_STATE_METHOD = all. This is true client side state saving.
3] javax.faces.STATE_SAVING_METHOD = client and org.apache.myfaces.trinidad.CLIENT_STATE_METHOD = token. This uses trinidad's token/cache. Trinidad's token/cache mechanism handles multiple windows correctly.
However in JSF 2 server side state saving (#1 above) no longer works. There are 2 solutions
A] Continue to delegate to the RI's stateManager but instead of using our coreResponseStateManager use the the RI's ResponseStateManager.
B] Stop delegating to the RI's stateManager and make 1] and 3] use the trinidad token/cache mechanism
My vote is for B since trinidad's token/cache does everything the RI's caching does, plus it handles multiple windows correctly.
> Trinidad 2 - server side state saving does not work
> ---------------------------------------------------
>
> Key: TRINIDAD-1642
> URL: https://issues.apache.org/jira/browse/TRINIDAD-1642
> Project: MyFaces Trinidad
> Issue Type: Bug
> Reporter: Gabrielle Crawford
> Assignee: Gabrielle Crawford
>
> Server side state saving is not working in Trinidad 2.0, instead of writing a token to the client the full state is written to the client.
> In Trinidad we have
> * our own stateManager which wraps the RI's state manager.
> * our own responseStateManager which does not wrap the RI's state manager
> For server side state saving we delegate to the RI's state manager. In JSF 1.2 the RI's stateManager handled saving the state on the session for server side state saving. So server side state saving worked in Trinidad 1.2.
> In JSF 2.0 the StateManager no longer handles server side state saving, now the ResponseStateManager handles server side state saving. Trinidad's CoreResponseStateManager just writes out whatever state it was given, so it writes out the full state instead of writing out a token and saving the state in the session.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (TRINIDAD-1642) Trinidad 2 - server side state
saving does not work
Posted by Gabrielle Crawford <ga...@oracle.com>.
yes, it looks like the responsibilities of the statemanager vs
responsestatemanager have changed in JSF 2.0.
Thanks,
Gab
Pavitra Subramaniam wrote:
> >> In JSF 2.0 the StateManager no longer handles server side state saving, now the ResponseStateManager handles server side state saving. Trinidad's CoreResponseStateManager just writes out whatever state it was given, so it writes out the full state instead of writing out a token and saving the state in the session.
> Does this change in JSF 2.0, also explain the NPE I am seeing with
> JIRA issue 1639? <http://issues.apache.org/jira/browse/TRINIDAD-1639>
>
> When doing a postback for the simple testcase I created, the
> CoreResponseStateManager actually returned null for getViewState()
> (rather than return the full state), which caused the NPE.
>
> Thanks
> Pavitra
>
> "Gabrielle Crawford (JIRA) wrote:" On 11/18/2009 2:54 PM PT:
>> [ https://issues.apache.org/jira/browse/TRINIDAD-1642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12779714#action_12779714 ]
>>
>> Gabrielle Crawford commented on TRINIDAD-1642:
>> ----------------------------------------------
>>
>> that should be
>> our own responseStateManager which does not wrap the RI's responseStateManager
>>
>>
>>> Trinidad 2 - server side state saving does not work
>>> ---------------------------------------------------
>>>
>>> Key: TRINIDAD-1642
>>> URL: https://issues.apache.org/jira/browse/TRINIDAD-1642
>>> Project: MyFaces Trinidad
>>> Issue Type: Bug
>>> Reporter: Gabrielle Crawford
>>> Assignee: Gabrielle Crawford
>>>
>>> Server side state saving is not working in Trinidad 2.0, instead of writing a token to the client the full state is written to the client.
>>> In Trinidad we have
>>> * our own stateManager which wraps the RI's state manager.
>>> * our own responseStateManager which does not wrap the RI's state manager
>>> For server side state saving we delegate to the RI's state manager. In JSF 1.2 the RI's stateManager handled saving the state on the session for server side state saving. So server side state saving worked in Trinidad 1.2.
>>> In JSF 2.0 the StateManager no longer handles server side state saving, now the ResponseStateManager handles server side state saving. Trinidad's CoreResponseStateManager just writes out whatever state it was given, so it writes out the full state instead of writing out a token and saving the state in the session.
>>>
>>
>>
Re: [jira] Commented: (TRINIDAD-1642) Trinidad 2 - server side state
saving does not work
Posted by Pavitra Subramaniam <pa...@oracle.com>.
>> In JSF 2.0 the StateManager no longer handles server side state saving, now the ResponseStateManager handles server side state saving. Trinidad's CoreResponseStateManager just writes out whatever state it was given, so it writes out the full state instead of writing out a token and saving the state in the session.
Does this change in JSF 2.0, also explain the NPE I am seeing with JIRA
issue 1639? <http://issues.apache.org/jira/browse/TRINIDAD-1639>
When doing a postback for the simple testcase I created, the
CoreResponseStateManager actually returned null for getViewState()
(rather than return the full state), which caused the NPE.
Thanks
Pavitra
"Gabrielle Crawford (JIRA) wrote:" On 11/18/2009 2:54 PM PT:
> [ https://issues.apache.org/jira/browse/TRINIDAD-1642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12779714#action_12779714 ]
>
> Gabrielle Crawford commented on TRINIDAD-1642:
> ----------------------------------------------
>
> that should be
> our own responseStateManager which does not wrap the RI's responseStateManager
>
>
>> Trinidad 2 - server side state saving does not work
>> ---------------------------------------------------
>>
>> Key: TRINIDAD-1642
>> URL: https://issues.apache.org/jira/browse/TRINIDAD-1642
>> Project: MyFaces Trinidad
>> Issue Type: Bug
>> Reporter: Gabrielle Crawford
>> Assignee: Gabrielle Crawford
>>
>> Server side state saving is not working in Trinidad 2.0, instead of writing a token to the client the full state is written to the client.
>> In Trinidad we have
>> * our own stateManager which wraps the RI's state manager.
>> * our own responseStateManager which does not wrap the RI's state manager
>> For server side state saving we delegate to the RI's state manager. In JSF 1.2 the RI's stateManager handled saving the state on the session for server side state saving. So server side state saving worked in Trinidad 1.2.
>> In JSF 2.0 the StateManager no longer handles server side state saving, now the ResponseStateManager handles server side state saving. Trinidad's CoreResponseStateManager just writes out whatever state it was given, so it writes out the full state instead of writing out a token and saving the state in the session.
>>
>
>
[jira] Commented: (TRINIDAD-1642) Trinidad 2 - server side state
saving does not work
Posted by "Gabrielle Crawford (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/TRINIDAD-1642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12779714#action_12779714 ]
Gabrielle Crawford commented on TRINIDAD-1642:
----------------------------------------------
that should be
our own responseStateManager which does not wrap the RI's responseStateManager
> Trinidad 2 - server side state saving does not work
> ---------------------------------------------------
>
> Key: TRINIDAD-1642
> URL: https://issues.apache.org/jira/browse/TRINIDAD-1642
> Project: MyFaces Trinidad
> Issue Type: Bug
> Reporter: Gabrielle Crawford
> Assignee: Gabrielle Crawford
>
> Server side state saving is not working in Trinidad 2.0, instead of writing a token to the client the full state is written to the client.
> In Trinidad we have
> * our own stateManager which wraps the RI's state manager.
> * our own responseStateManager which does not wrap the RI's state manager
> For server side state saving we delegate to the RI's state manager. In JSF 1.2 the RI's stateManager handled saving the state on the session for server side state saving. So server side state saving worked in Trinidad 1.2.
> In JSF 2.0 the StateManager no longer handles server side state saving, now the ResponseStateManager handles server side state saving. Trinidad's CoreResponseStateManager just writes out whatever state it was given, so it writes out the full state instead of writing out a token and saving the state in the session.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1642) Trinidad 2 - server side state
saving does not work
Posted by "Matthias Weßendorf (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/TRINIDAD-1642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12786373#action_12786373 ]
Matthias Weßendorf commented on TRINIDAD-1642:
----------------------------------------------
B) sounds fine with me, but I see this ticket has already been solved ...
> Trinidad 2 - server side state saving does not work
> ---------------------------------------------------
>
> Key: TRINIDAD-1642
> URL: https://issues.apache.org/jira/browse/TRINIDAD-1642
> Project: MyFaces Trinidad
> Issue Type: Bug
> Reporter: Gabrielle Crawford
> Assignee: Gabrielle Crawford
> Fix For: 2.0.0-core
>
>
> Server side state saving is not working in Trinidad 2.0, instead of writing a token to the client the full state is written to the client.
> In Trinidad we have
> * our own stateManager which wraps the RI's state manager.
> * our own responseStateManager which does not wrap the RI's state manager
> For server side state saving we delegate to the RI's state manager. In JSF 1.2 the RI's stateManager handled saving the state on the session for server side state saving. So server side state saving worked in Trinidad 1.2.
> In JSF 2.0 the StateManager no longer handles server side state saving, now the ResponseStateManager handles server side state saving. Trinidad's CoreResponseStateManager just writes out whatever state it was given, so it writes out the full state instead of writing out a token and saving the state in the session.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TRINIDAD-1642) Trinidad 2 - server side state
saving does not work
Posted by "Gabrielle Crawford (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/TRINIDAD-1642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Gabrielle Crawford resolved TRINIDAD-1642.
------------------------------------------
Resolution: Fixed
Fix Version/s: 2.0.0-core
> Trinidad 2 - server side state saving does not work
> ---------------------------------------------------
>
> Key: TRINIDAD-1642
> URL: https://issues.apache.org/jira/browse/TRINIDAD-1642
> Project: MyFaces Trinidad
> Issue Type: Bug
> Reporter: Gabrielle Crawford
> Assignee: Gabrielle Crawford
> Fix For: 2.0.0-core
>
>
> Server side state saving is not working in Trinidad 2.0, instead of writing a token to the client the full state is written to the client.
> In Trinidad we have
> * our own stateManager which wraps the RI's state manager.
> * our own responseStateManager which does not wrap the RI's state manager
> For server side state saving we delegate to the RI's state manager. In JSF 1.2 the RI's stateManager handled saving the state on the session for server side state saving. So server side state saving worked in Trinidad 1.2.
> In JSF 2.0 the StateManager no longer handles server side state saving, now the ResponseStateManager handles server side state saving. Trinidad's CoreResponseStateManager just writes out whatever state it was given, so it writes out the full state instead of writing out a token and saving the state in the session.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.