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