Blake, you are totally correct.. I MAY be able to save this state on
the Trinidad page-flow scope, but I think that there are usecases that
pop this scope which may make it unavailable. Would you like me to
research this?
Another option might be to clean up on subsequent normal requests, but I
personally think that would open up some additional potential for breakage.
As for the amount of data being stored, I'm only storing a viewId (which
is a string obviously) and the LAUNCH_PARAMETERS. While Adam was
concerned that the launch-parameters might be too big for a get request,
I'm not sure that we're talking about an excessive amount of data here.
But I'm certainly open to ideas about how to clean this failover usecase
up earlier.
Scott
Blake Sullivan wrote:
The tricky issue with remembering this state in the server is cleaning
up if the redirect request never comes back. If you are content to
wait until the session times-out, or there is another dialog request,
then it isn't a problem.
-- Blake Sullivan
Scott O'Bryan (JIRA) said the following On 9/16/2008 10:10 AM PT:
[ https://issues.apache.org/jira/browse/TRINIDAD-1203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12631469#action_12631469 ]
Scott O'Bryan commented on TRINIDAD-1203:
-----------------------------------------
I think I'm going to submit a patch which does something similar to this one
and I'd like to get people to review it. As I said before, I'm somewhat
reluctant to do this through a forward because it would change filter logic or
whatnot. I believe, however, that we can issue a redirect and then have the
filter set up the appropriate environment for us. This also moves us one one
step closer to being able to solve TRINIDAD-55 which has been open for a long
time. Portlet containers support redirects.
I'm going to start of by preserving the LAUNCH_PARAMETERS and the VIEW_ID. To
get over any concerns with the size of the redirect code, I'm going to tokenize
the request and keep track of the LAUNCH_PARAMETERS on the server side.
Hopefully this will solve the issue. Once I submit the patch, I'll ask for
input from the community so I make sure we don't break anyone.
DATE SELECTION IN INPUTDATE ON BLACKBERRY THROWS VIEWEXPIREDEXCEPTION
---------------------------------------------------------------------
Key: TRINIDAD-1203
URL: https://issues.apache.org/jira/browse/TRINIDAD-1203
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Affects Versions: 1.2.9-core
Environment: WebLogic Server only. This is a specific to browsers that
do not support multiple windows (pop up).
Reporter: Tadashi Enomori
Assignee: Scott O'Bryan
Priority: Minor
Attachments: TRINIDAD-1203.patch, TRINIDAD-1203_1.0.patch
This problem is caused by the variation of filter chain implementation in servers. Trinidad filter implementation invokes chain.doFilter() for a same request, but WLS does not handle the case.
