[
https://issues.apache.org/jira/browse/PORTLETBRIDGE-62?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12670150#action_12670150
]
Michael Freedman commented on PORTLETBRIDGE-62:
-----------------------------------------------
Its a bug that this code doesn't test if the init parameter default content
type is valid for this request or not. I will modify the code to check
against the list of supported response content types.
As for why the init parameter was introduced: When the view is represented by
a JSP the bridge relies on dispatch.include to render the view. By JSR 168
spec rule, an included entity can't set the characterset encoding/contenttype
of a response. However, as we know JSPs do express the characterset/content of
their response. The biggest problem we addressed in adding these init
parameters is expressing the character set of the response. The bridge has no
clue (and hence doesn't set anything). If the portlet/JSP has somethign
specific, we can use this init parameter to preset it. We debated whether or
not to also include the ContentType init parameter. I can find the discussion
thread in our meeting minutes but it seems to peter out without a resolution.
I can only imagine I added it for completeness and to cover the rare situation
that the consumer says it can support multiple response types and the JSP
returns one of these valid types but its not the preferred one.
As for the second issue: the bridge checks to see if the response content type
is set and only if its not does it set it. So in the case of the GFP the GFP
initial setting isn't overwritten. The bridge code however isn't redundant
because there isn't a requirement that the portlet use the GFP. If it deals
with the bridge directly it may not have preset the ContentType. Hence the
bridge needs to ensure this. In thinking about it, this bridge code might
better be placed in the ExternalContext dispatch() method as then the bridge
would only set this value right before the include -- this would ensure no
collision with any other code that checks to see if the response content type
has already been set. However, this is an impl issue not a spec issue and I am
not sure we should move the code for fear of unknown/unexpected impacts. What
do you think?
> 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
>
> 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.
