[
https://issues.apache.org/jira/browse/PLUTO-523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12647241#action_12647241
]
Ate Douma commented on PLUTO-523:
---------------------------------
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).
> 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.
