1. Pluto
  2. PLUTO-532

New PortletResponseStateProvider SPI


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


      Below copied (in part) from email discussion on the Pluto dev list, see also:

          • new: PortletResponseStateProvider SPI
            The current PortletResponse (and derivate) implementations "write" the response state directly to the portal provided servlet response, or use the above described PropertyManager SPI (see: PLUTO-531)
            For the generated content output, this solution assumes (requires) that the portal provided servlet response properly deals with
            the required buffering, content type, etc. handling, but this is not appropriately captured in a SPI contract.
            In addition, essential JSR-286 features like CacheControl, PortletWindow title setting nextPossiblePortletModes, etc. are not yet implemented or in an unexpected way (RenderResponse.setTitle using PortalCallback.setTitle).

      In my view, all these response "state" parameters need to be dealt with as a single set as the aggregating portal will have to deal
      with then as a a single set anyway. For example, Once response caching is properly implemented, all these response state parameters need
      to be cached as one set. For that, one single SPI should be used instead of requiring a generic servlet response wrapper
      implementation by the Portal without any formal contract as well as having to "merge" with some other SPI callback method results too.

      I propose adding a new PortletResponseStateProvider SPI to take over the set* methods of the current PropertyManager SPI
      as well as for storing response content (and related attributes like contentType), PortletWindow title, nextPossiblePortletModes and the CacheControl. All PortletResponse (and dispatched Servletresponse) methods dealing with writing content state should delegate to this new SPI.
      The aggregating portal then can retrieve and process the resulting response state as a single entity after the portlet invocation is completed.


        Ate Douma created issue -
        Ate Douma made changes -
        Field Original Value New Value
        Status Open [ 1 ] In Progress [ 3 ]
        Ate Douma added a comment -

        All fixed and implemented with the recent big bang refactoring and final commits r753592 and r753593

        Ate Douma added a comment - All fixed and implemented with the recent big bang refactoring and final commits r753592 and r753593
        Ate Douma made changes -
        Status In Progress [ 3 ] Resolved [ 5 ]
        Resolution Fixed [ 1 ]
        Mark Thomas made changes -
        Workflow jira [ 12452974 ] Default workflow, editable Closed status [ 12565328 ]
        Mark Thomas made changes -
        Workflow Default workflow, editable Closed status [ 12565328 ] jira [ 12585985 ]
        Transition Time In Source Status Execution Times Last Executer Last Execution Date
        Open Open In Progress In Progress
        3s 1 Ate Douma 19/Feb/09 16:20
        In Progress In Progress Resolved Resolved
        22d 11h 5m 1 Ate Douma 14/Mar/09 03:25


          • Assignee:
            Ate Douma
            Ate Douma
          • Votes:
            0 Vote for this issue
            0 Start watching this issue


            • Created: