[PORTLETBRIDGE-14] Setting the request character encoding during a RenderRequest

• Type: Bug
• Status: Closed
• Priority: Critical
• Resolution: Fixed
• Affects Version/s: 1.0.0-alpha-2
• Fix Version/s: 1.0.0-alpha
• Component/s: API
• Environment: Tomcat 5.5.20, Pluto 1.1.4, MyFaces 1.2.1-SNAPSHOT (locally patched version)
• Assignee: Scott O'Bryan
• Reporter: Bernhard Huemer
• Created: 16/Nov/07 16:04
• Updated: 09/Sep/11 17:31
• Resolved: 21/Nov/07 22:49

Description

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)
  Unknown macro: { 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);
}

\\\