[
https://issues.apache.org/jira/browse/PLUTO-444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12544961
]
Christian Raschka commented on PLUTO-444:
-----------------------------------------
An idea strikes me, that this is not the final solution. The Problem is, that
you cannot postprocess after rendering (processAction etc.)
Maybe it could be a solution to use a "RenderFilter" which does normal
rendering and is the last filter in the chain ...
(And of course "ProcessActionFilter, ProcessEventFilter, ProcessResourceFilter.)
What do you think about this solution?
> Filter chain is not implemented the right way
> ---------------------------------------------
>
> Key: PLUTO-444
> URL: https://issues.apache.org/jira/browse/PLUTO-444
> Project: Pluto
> Issue Type: Sub-task
> Components: portal driver
> Affects Versions: 1.1-286-COMPATIBILITY, 1.1-286-trunk-merge
> Reporter: Christian Raschka
> Priority: Critical
> Fix For: 1.1-286-COMPATIBILITY, 1.1-286-trunk-merge
>
> Attachments: filter.231107.patch
>
>
> In my opinion portlet filter should work the same way like servlet filters do:
> An example: If you have a filter chain with filters F1 and F2, then the chain
> is: F1 -> F2 -> target -> F2 -> F1.
> An exception is, if a Filter does not call filterChain.doFilter. Then no
> other filter _or_ the target is invoked and the filter itself is responsible
> for the response.
> (e.g. see http://java.sun.com/products/servlet/Filters.html)
> In the current implementation the target is invoked, no matter if a filter
> blocks the chain or not.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
