Pluto
  1. Pluto
  2. PLUTO-478

Portlet Dispatching loses wrappers

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.0.0
    • Fix Version/s: 2.0.0
    • Component/s: portlet container
    • Labels:
      None

      Description

      When you dispatch using a wrapped request/response object, pluto doesn't preserve the wrapping when it executes the dispatch. I.e. it upwraps the request/response and dispatches on that. This prevents portlets from filtering request/responses to/from dispatched/servlet entities.

      It would be nice if we added a TCK test for this case as well. The spec is clear that one can use a wrapped request/response to dispatch to. Though it doesn't specifically state that this must be preserved, it not only is the reasonable interpreation/expectation but is what clients will be counting on. Hence for the sake of interoperability, having a TCK test will catch this problem early.

        Activity

        Michael Freedman created issue -
        Michael Freedman made changes -
        Field Original Value New Value
        Description When you dispatch using a wrapped request/response object, pluto doesn't preserve the wrapping when it executes the dispatch. I.e. it upwraps the request/response and dispatches on that. This prevents portlets from filtering request/responses to/from dispatched/servlet entities. When you dispatch using a wrapped request/response object, pluto doesn't preserve the wrapping when it executes the dispatch. I.e. it upwraps the request/response and dispatches on that. This prevents portlets from filtering request/responses to/from dispatched/servlet entities.

        It would be nice if we added a TCK test for this case as well. The spec is clear that one can use a wrapped request/response to dispatch to. Though it doesn't specifically state that this must be preserved, it not only is the reasonable interpreation/expectation but is what clients will be counting on. Hence for the sake of interoperability, having a TCK test will catch this problem early.
        Ate Douma made changes -
        Assignee Ate Douma [ adouma ]
        Ate Douma made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Resolution Fixed [ 1 ]
        Mark Thomas made changes -
        Workflow jira [ 12427306 ] Default workflow, editable Closed status [ 12564873 ]
        Mark Thomas made changes -
        Workflow Default workflow, editable Closed status [ 12564873 ] jira [ 12585966 ]

          People

          • Assignee:
            Ate Douma
            Reporter:
            Michael Freedman
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development