[
https://issues.apache.org/jira/browse/PORTLETBRIDGE-62?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Freedman resolved PORTLETBRIDGE-62.
-------------------------------------------
Resolution: Fixed
Fix Version/s: 2.0.0
1.0.0
Content type now resolved properly.
> GFP.getResponseContentType breaks Portlet Spec PLT.12.3.1
> ---------------------------------------------------------
>
> Key: PORTLETBRIDGE-62
> URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-62
> Project: MyFaces Portlet Bridge
> Issue Type: Bug
> Components: API
> Affects Versions: 1.0.0-beta
> Reporter: Jondean Haley
> Assignee: Michael Freedman
> Fix For: 1.0.0, 2.0.0
>
>
> method:
> public String getResponseContentType(PortletRequest request)
> {
> String contentType =
>
> getPortletConfig().getPortletContext().getInitParameter(DEFAULT_CONTENT_TYPE);
> if (contentType == null)
> {
> contentType = request.getResponseContentType();
> }
> return contentType;
> }
> This method is used by GFP.setResponseContentType.
> Problem, by PLT.12.3.1 - PortletResponse.setResponseContentType MUST set a
> content type from the set returned from
> PortletRequest.getResponseContentTypes, which is the set formed by the
> intersection of those types supported by the portal AND the portlet, as
> defined in portlet.xml. The method above sets the content type to an
> arbitrary init parm in preference to using the default type as defined by
> both the portal and portlet (and further, the current mode). If I set this
> init parm to "hello", I break the spec. If this init parm is set to a value
> that the portal cannot support, the portal behavior is undefined, but it can
> throw an exception on receipt of the HTTPS response with a content type that
> is not part of its requested set.
> Why was this init parm introduced? It appears unnecessary.
> DEFAULT_CONTENT_TYPE does not appear in the Spec Ch.3 on init parms. The
> portlet.xml handles default content type, as returned from
> PortletRequest.getReponseContentType(), which, by spec, MUST be the first
> content type returned from the set-returning getResponseContentTypes().
> A 2nd issue: BridgeImpl.doFacesRequest sets the content-type again,
> overwriting that of doDispatch in the GFP (which uses the above method).
> Code of BridgeImpl.doFacesRequest:
> if (extCtx.getResponseContentType() == null)
> {
> response.setContentType(extRequest.getResponseContentType());
> }
> It appears that this can and should be removed. This may be why use of
> DEFAULT_CONTENT_TYPE has not been a problem so far.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
