[
https://issues.apache.org/jira/browse/PLUTO-532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ate Douma resolved PLUTO-532.
-----------------------------
Resolution: Fixed
All fixed and implemented with the recent big bang refactoring and final
commits r753592 and r753593
> New PortletResponseStateProvider SPI
> ------------------------------------
>
> Key: PLUTO-532
> URL: https://issues.apache.org/jira/browse/PLUTO-532
> Project: Pluto
> Issue Type: Improvement
> Components: portlet container
> Affects Versions: 2.0.0
> Reporter: Ate Douma
> Assignee: Ate Douma
> Fix For: 2.0.0
>
>
> Below copied (in part) from email discussion on the Pluto dev list, see also:
> http://www.nabble.com/More-required-Pluto-2.0-SPI-and-implementation-refactoring-issues-td21973310.html
> *** 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
