Pluto
  1. Pluto
  2. PLUTO-523

Further abstractions of the Pluto SPI to support embedding in and extending by other portals

    Details

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

      Description

      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.

        Activity

        Ate Douma created issue -
        Hide
        Ate Douma added a comment -

        Abstracting the PortletRequestImpl.getContextPath() to delegate to new method InternalPortletContext.getContextPath().
        This allows other portals like Jetspeed to easily override this without having to wrap all the PortletRequest class implementations.
        Use case for Jetspeed is supporting "local" portlet applications which run within a different context (the portal in this case).

        Show
        Ate Douma added a comment - Abstracting the PortletRequestImpl.getContextPath() to delegate to new method InternalPortletContext.getContextPath(). This allows other portals like Jetspeed to easily override this without having to wrap all the PortletRequest class implementations. Use case for Jetspeed is supporting "local" portlet applications which run within a different context (the portal in this case).
        Hide
        Ate Douma added a comment -
        • 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
        Show
        Ate Douma added a comment - 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
        Hide
        Ate Douma added a comment -

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

        Show
        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 -
        Field Original Value New Value
        Status Open [ 1 ] Resolved [ 5 ]
        Resolution Fixed [ 1 ]
        Mark Thomas made changes -
        Workflow jira [ 12446203 ] Default workflow, editable Closed status [ 12564874 ]
        Mark Thomas made changes -
        Workflow Default workflow, editable Closed status [ 12564874 ] jira [ 12585965 ]

          People

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

            Dates

            • Created:
              Updated:
              Resolved:

              Development