[jira] Commented: (PORTLETBRIDGE-62) GFP.getResponseContentType breaks Portlet Spec PLT.12.3.1

["Michael Freedman (JIRA)" <de...@myfaces.apache.org>]

    [ 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.