Details

    • Type: Sub-task Sub-task
    • Status: Resolved
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 1.1-286-COMPATIBILITY, 2.0.0
    • Fix Version/s: 1.1-286-COMPATIBILITY, 2.0.0
    • Component/s: portal driver
    • Labels:
      None

      Description

      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.

      1. filters.271107.patch
        13 kB
        Christian Raschka
      2. filter.231107.patch
        11 kB
        Christian Raschka

        Activity

        Hide
        Christian Raschka added a comment -

        This patch implements this functionality and works as follows:

        The FilterManager.processFilter() method returns a boolean, if the normal lifecycle should process or not.

        It gets its information from a boolean field in the FilterChainImpl which is set to "normal", if there are no filters or the index of filter is size+1. This means, that the doFilter() method is invoked, but no filter exists anymore. -> Invoke normal lifecycle.

        Show
        Christian Raschka added a comment - This patch implements this functionality and works as follows: The FilterManager.processFilter() method returns a boolean, if the normal lifecycle should process or not. It gets its information from a boolean field in the FilterChainImpl which is set to "normal", if there are no filters or the index of filter is size+1. This means, that the doFilter() method is invoked, but no filter exists anymore. -> Invoke normal lifecycle.
        Hide
        Christian Raschka added a comment -

        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?

        Show
        Christian Raschka added a comment - 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?
        Hide
        Christian Raschka added a comment -

        Here is my next version. It should now be spec conform as i have described above.

        The portlet instance is set to the filterchain and the render (processAction etc.) is done there if no (more) filters are present.

        Please review it.

        TODO: The Filters need a refactoring (merge things used in all lifecycles)

        Show
        Christian Raschka added a comment - Here is my next version. It should now be spec conform as i have described above. The portlet instance is set to the filterchain and the render (processAction etc.) is done there if no (more) filters are present. Please review it. TODO: The Filters need a refactoring (merge things used in all lifecycles)
        Hide
        Craig Doremus added a comment -

        I applied the latest patch (filters.271107.patch) to the 1.1-286-trunk-merge branch. When the portal is built, the content of all portlets do not get rendered and have a 'null' portlet title. This occurs because the calls in PortletServlet.dispatch() that are comment out with the "Should be called in the filtermanager" comment above them are not called in FilterManagerImpl or within its call stack. If I restore the commented out calls, the portlets are rendered properly, but most of the the testsuite filter tests in PLUTO-442 (pluto-testsuite.afewfiltertests.patch) do not work correctly. I'm not sure if this has to do with the patch in this issue or the one in PLUTO-442.

        Show
        Craig Doremus added a comment - I applied the latest patch (filters.271107.patch) to the 1.1-286-trunk-merge branch. When the portal is built, the content of all portlets do not get rendered and have a 'null' portlet title. This occurs because the calls in PortletServlet.dispatch() that are comment out with the "Should be called in the filtermanager" comment above them are not called in FilterManagerImpl or within its call stack. If I restore the commented out calls, the portlets are rendered properly, but most of the the testsuite filter tests in PLUTO-442 (pluto-testsuite.afewfiltertests.patch) do not work correctly. I'm not sure if this has to do with the patch in this issue or the one in PLUTO-442 .
        Hide
        Christian Raschka added a comment -

        It seems, that something is missing in the patch. I will looking into this ...

        Thank you Craig for all your hard work towards a Pluto 2.0.

        Show
        Christian Raschka added a comment - It seems, that something is missing in the patch. I will looking into this ... Thank you Craig for all your hard work towards a Pluto 2.0.
        Hide
        Christian Raschka added a comment -

        It seems, that there is a problem, with the moment the filter configs are loaded. Craig could you please test, if everything is ok, if you restart tomcat after deploying the portlet.

        With me the filterchain isn't found after deploying, and therefor rendering doesn't occur (it is the last entry in the FilterChain.)

        Btw. the comment should be: "Should be called in the FilterChain" and it is in the patch.

        Show
        Christian Raschka added a comment - It seems, that there is a problem, with the moment the filter configs are loaded. Craig could you please test, if everything is ok, if you restart tomcat after deploying the portlet. With me the filterchain isn't found after deploying, and therefor rendering doesn't occur (it is the last entry in the FilterChain.) Btw. the comment should be: "Should be called in the FilterChain" and it is in the patch.
        Hide
        Ate Douma added a comment -

        Patch was applied long time ago

        Show
        Ate Douma added a comment - Patch was applied long time ago

          People

          • Assignee:
            Unassigned
            Reporter:
            Christian Raschka
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development