myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Scott O'Bryan" <>
Date Tue, 16 Sep 2008 20:42:32 GMT
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.


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:
>>     [
>> 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
>>> ---------------------------------------------------------------------
>>>                 Key: TRINIDAD-1203
>>>                 URL:
>>>             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. 

View raw message