[jira] Commented: (TRINIDAD-1203) DATE SELECTION IN INPUTDATE ON BLACKBERRY THROWS VIEWEXPIREDEXCEPTION

["Scott O'Bryan (JIRA)" <de...@myfaces.apache.org>]

    [ https://issues.apache.org/jira/browse/TRINIDAD-1203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12627839#action_12627839 ] 

Scott O'Bryan commented on TRINIDAD-1203:
-----------------------------------------

I think we need to be very careful about applying this patch.  It seems the patch is taking a fairly interesting approach.  Some years ago, Adam (the original author of this logic) and I discussed changing this re-execution of the filter chain in order to support Portals.  The "forward" approach was not discussed because portal's didn't support them.  As such, we discussed redirects.  His issue with the redirect is that redirects are GET requests and the amount of posted in data may exceed an appropriate size.  Indeed the forward eliminates this issue, but it may well cause others.  For example:

  1. Filters are not executed on a forward or include by default.  As such, where the doFilter would re-execute any filters in the chain, the "forward" approach would not.  Setting them up to execute on forwards could well have adverse effects in that filters may be applied multiple times.  Let's not forget that both faces and the bridge do a forward at some point during the lifecycle.  Configuring the filter to work off a forward might re-apply these filters.

2. There may be some containers whose response is committed by the end of the initial doFilter.  If this is the case, the forward would throw an exception.

3. This solution may well impact our ability to handle Trinidad Dialogs from a portlet environment.  Currently we do not support trinidad dialogs in portlets, but there is an open JIRA ticket and I was hoping to be able to do this in Portlet 2.0.  Although Portlet 2.0 supports forward, I'm not sure if this scenario would necessarily be supported.

Besides some of the concerns, this solution should be moved to a configurator and handled there.  It remained in the Trinidad filters because it needed to re-run the filter chain, something that configurators could not do.  Configurators CAN forward, however, and it would allow us to have custom logic for both portlets AND servlets. I guess in short, I would be very reluctant to put a change like this in until we've had a chance to figure out all of its implications, especially with other pieces of the ADF stack like ADFm, ADF-Bindings, and ADFc.

Some alternatives to this would be to handle this re-execution of the lifecycle at the faces level instead of at the filter level.  Adam and I toyed with the idea of possibly adding a Trinidad lifecycle which would simulate this re-execution.  Another alternative is to revisit the dialog framework altogether and see if there is not a way to combine processing of the dialog view root with the new view root.

One question I do need to ask is this.  What exception does WLS throw when the doFilter is re-executed?  J2EE says that an IOException or a ServletException are the only allowed exceptions which may be thrown.  Certainly a chain to be executed twice does not seem like either one of these exceptions and it seems to me that the javadoc is pretty clear as to what is supposed to happen.


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

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.