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