[jira] Commented: (PLUTO-523) Further abstractions of the Pluto SPI to support embedding in and extending by other portals

["Ate Douma (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/PLUTO-523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12667826#action_12667826 ] 

Ate Douma commented on PLUTO-523:
---------------------------------

- adding new PortletContainer enum Method type defining the specific supported container methods (.e.g. render/resource/action/admin/load)
- recording current invoked Method enum value in ContainerInvocation so it can be evaluated/used within container processing logic 
- fixing the PortletRequestDispatcher.forward method to actually call (servlet) rd.forward instead of "faking" it through an rd.include
- adjusting DefaultPortletInvokerService to use forwards for PortletContainer.Method.RESOURCE
- adding get/set properties methods to PortletURLProvider as formally required by the spec (no real implementation needed: this is intended for "vendor" specific properties handling)
- replacing the RequestPropertyProvider (which internal implementation was really, really messy and broken in many ways) by more generic PropertyManager (very similar to old Pluto 1.1.x PropertyManager actually).
- PropertyManager.setProperty (response headers) will write them to the servlet.response when PortletContainer.Method.RESOURCE, setProperty(Cookie) will now always be written out

> Further abstractions of the Pluto SPI to support embedding in and extending by other portals 
> ---------------------------------------------------------------------------------------------
>
>                 Key: PLUTO-523
>                 URL: https://issues.apache.org/jira/browse/PLUTO-523
>             Project: Pluto
>          Issue Type: Task
>    Affects Versions: 2.0.0
>            Reporter: Ate Douma
>            Assignee: Ate Douma
>             Fix For: 2.0.0
>
>
> While the mayor Pluto 2.0 SPI refactoring from PLUTO-481 is done, we're encountering new, although smaller, issues with getting Jetspeed running with Pluto 2.0.
> As an example, the Pluto PortletRequestImpl.getContextPath() uses the PortletApplication name to derive the contextPath.
> This works for "normal" portlet applications but Jetspeed also has a "local" portlet application feature, which means the context path of such an application actually is the (Jetspeed) portal application.
> To support overriding this getContextPath() resolution (without wrapping each and every PortletRequestImpl), I'm moving this to a new InternalPortletContext.getContextPath (similar with Servlet 2.5 ServletContext.getContextPath).
> As Jetspeed already overrides/wraps the InternalContextPath, we now can easily adjust the returned contextPath based on the type of portlet application (local vs. plain webapp)
> This issue, I'll keep open as overall item to record similar small SPI refactoring changes.
> Another coming up (not done yet) is the PortletURLProvider interface which doesn't yet encapsulates resourceURL Cacheability or ResourceID state.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.