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.
