[jira] Commented: (PORTLETBRIDGE-14) Setting the request character encoding during a RenderRequest

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

    [ https://issues.apache.org/jira/browse/PORTLETBRIDGE-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12543143 ] 

Michael Freedman commented on PORTLETBRIDGE-14:
-----------------------------------------------

I think your problem is actually caused by Pluto presenting the CONTENT-TYPE header in the subsequent request as the Faces RI mistakenly adds the session attribute at the APPLICATION_SCOPE but tries and reads it from the PORTLET_SCOPE -- so it never finds it.  We haven't encountered this problem because we are running in a WSRP environment where these headers aren't explicitly exposed (just accessible via the portlet APIs).  Anyway I need to talk to the EG some about what should happen here before attempting a fix.  As a short term workaround just change PEXI.setCharacterEncoding to be a noop if not in an Action vs. throwing the exception.

> Setting the request character encoding during a RenderRequest
> -------------------------------------------------------------
>
>                 Key: PORTLETBRIDGE-14
>                 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-14
>             Project: MyFaces Portlet Bridge
>          Issue Type: Bug
>    Affects Versions: 1.0.0-SNAPSHOT
>         Environment: Tomcat 5.5.20, Pluto 1.1.4, MyFaces 1.2.1-SNAPSHOT (locally patched version)
>            Reporter: Bernhard Huemer
>            Priority: Critical
>         Attachments: Pluto Screenshot.jpg, Stacktrace.jpg
>
>
> The JSF specification requires the ViewHandler to store the content-type in the session at the end of the render-response phase (see 2.5.2.2 "Determining the Character Encoding"). On subsequent render requests the view will be restored (actually, a new one will be created but that doesn't matter) and during this task the ViewHandler tries to set the request character encoding. 
> /// myfaces-api/src/main/java/javax/faces/application/ViewHandler.java
> /**
>  * Method must be called by the JSF impl at the beginning of Phase <i>Restore View</i> of the JSF
>  * lifecycle.
>  * 
>  * @since JSF 1.2
>  */
> public void initView(javax.faces.context.FacesContext context) throws FacesException
> {
>   String _encoding = this.calculateCharacterEncoding(context);
>   if(_encoding != null)
>   {
>     try
>     {
>       context.getExternalContext().setRequestCharacterEncoding(_encoding);
>     }
>     catch(UnsupportedEncodingException uee)
>     {
>       throw new FacesException(uee);	
>     }
>   }
> }
> \\\ 
> However, this attempt fails as the portlet bridge requires the request to be an ActionRequest.
> ///  portlet-bridge-impl/src/main/java/org/apache/myfaces/portlet/faces/context/PortletExternalContextImpl
> public void setRequestCharacterEncoding(String encoding) throws UnsupportedEncodingException,
>                                                         IllegalStateException
> {
>   if (mPhase != Bridge.PortletPhase.ActionPhase)
>   {
>     throw new IllegalStateException(
>                                     "PortletExternalContextImpl.setRequestCharacterEncoding(): Request must be an ActionRequest");
>   }
>   ((ActionRequest) mPortletRequest).setCharacterEncoding(encoding);
> }
> \\\

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.