You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by "Bernhard Huemer (JIRA)" <de...@myfaces.apache.org> on 2007/11/16 17:05:43 UTC
[jira] Created: (PORTLETBRIDGE-14) Setting the request character
encoding during a RenderRequest
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
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.
[jira] Commented: (PORTLETBRIDGE-14) Setting the request character
encoding during a RenderRequest
Posted by "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.
[jira] Resolved: (PORTLETBRIDGE-14) Setting the request character
encoding during a RenderRequest
Posted by "Scott O'Bryan (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/PORTLETBRIDGE-14?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Scott O'Bryan resolved PORTLETBRIDGE-14.
----------------------------------------
Resolution: Fixed
Issue resolved by patch in PORTLETBRIDGE-3 issue.
> 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
> Components: API
> 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
> Assignee: Scott O'Bryan
> Priority: Critical
> Fix For: 1.0.0-SNAPSHOT
>
> 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.