[
https://issues.apache.org/jira/browse/PLUTO-781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16931747#comment-16931747
]
Steve Potter commented on PLUTO-781:
------------------------------------
Thanks for spotting the fault in my test application. Stepping through the
updated code, I can see that PortletMVC4Spring is forcing the dispatch to be an
'include' rather than a 'forward' in PortletJstlView.useInclude when the
requester is Pluto, avoiding the unexpected forward behaviour. Unfortunately
this is not useful for us, and we are back to the original problem of Pluto not
supporting a 'forward' to a resource.
> PortletRequestDispatcherImpl forwards to incorrect path
> -------------------------------------------------------
>
> Key: PLUTO-781
> URL: https://issues.apache.org/jira/browse/PLUTO-781
> Project: Pluto
> Issue Type: Bug
> Components: portlet container
> Affects Versions: 3.0.1
> Environment: Pluto Container 3.0.1, Spring 4.0.9.RELEASE, Wildfly
> 14.0.1
> Reporter: Steve Potter
> Assignee: Neil Griffin
> Priority: Major
> Attachments: pluto-debug.txt, test-portlet-mvc.zip, test-portlet.zip
>
>
> When a serveResource method forwards to a servlet which then forwards to a
> jsp, the HttpServletPortletRequestWrapper provides the path from the first
> forward rather than the second forward and the jsp is not rendered.
> This is the process used by Spring Portlet MVC to locate JSP 'views'
> resulting in the failure of all our portlets when trying to serve JSP's in
> response to resource requests.
> The attached file contains a DEBUG log of the processing flow attempting to
> serve '/WEB-INF/jsp/resource2.jsp' in response to a resource request.
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
