The portlet specification allows for most of the interesting HttpServletResponse.set* methods to be mapped back to the corresponding ResourceResponse methods but ONLY if the portlet uses PortletRequestDisptacher.forward. If include is used the HttpServletResponse.set* methods are ignored.
This is especially important when using special views such as Jackson or CSV where a specific content-type or other headers need to be set.
That include call dates back to Portlet 1.0 where all we had was the include operation for render requests.
For resource requests, it seems that include doesn't actually make much sense? That would only be useful if the original resource request already got included somewhere else, which is rather unlikely. Is it even technically possible in the Portlet resource request model? Can you manually include another portlet's processing of a specific resource id?
I'm basically considering to always use a forward for resource requests and not even bother with a flag.
I've never seen a case where the include in a resource is used. I added the flag in the patch for compatibility but my original local fix in uPortal always used forward for resource handling.
Alright, I went with the straight forward for resource requests, extracting a doDispatch method that can be overridden if somebody really insists. I don't think anyone will, and we've got so many configuration options already...
Eric Dalquist opened SPR-9876 and commented
The portlet specification allows for most of the interesting HttpServletResponse.set* methods to be mapped back to the corresponding ResourceResponse methods but ONLY if the portlet uses PortletRequestDisptacher.forward. If include is used the HttpServletResponse.set* methods are ignored.
This is especially important when using special views such as Jackson or CSV where a specific content-type or other headers need to be set.
Affects: 3.1.2
Issue Links:
@resourceMapping
doesn't work.The text was updated successfully, but these errors were encountered: