You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by "Michael Freedman (JIRA)" <de...@myfaces.apache.org> on 2010/08/05 23:29:21 UTC
[jira] Created: (PORTLETBRIDGE-162) Portlet 2.0 Bridge: Resource as
source of iFrame doesn't render in Pluto
Portlet 2.0 Bridge: Resource as source of iFrame doesn't render in Pluto
------------------------------------------------------------------------
Key: PORTLETBRIDGE-162
URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-162
Project: MyFaces Portlet Bridge
Issue Type: Bug
Components: Impl
Affects Versions: 2.0.0-beta
Reporter: Michael Freedman
Assignee: Michael Freedman
If the resource target for the above is a Face view, the bridge runs through/executesd the normal Faces lifecycle to render the resource. It dispatches to the view JSP using forward. In the regular case (nonResource) this is actually translated by Pluto into a servlet include simulating the forward. However for a resource its an actual servlet forward. Tomcat closes the response and flushes the markup (from it) at the end of the forward. So unless the response is wrapped/buffered Faces can't write after the forward.
So the solution is to be sure the response is always wrapped/buffered (similar to the base Faces implementation). Do this for all requests (render and resource) as we don't know how the portlet container we are running on may be working
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (PORTLETBRIDGE-162) Portlet 2.0 Bridge: Resource
as source of iFrame doesn't render in Pluto
Posted by "Michael Freedman (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/PORTLETBRIDGE-162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Michael Freedman resolved PORTLETBRIDGE-162.
--------------------------------------------
Fix Version/s: 2.0.0
Resolution: Fixed
So the bridge now always wraps before dispatching. -- Code has been updated to reflect recent spec change in this area -- the developer can specify the wrapper class to use in faces-config.xml. If that isn't done the bridge uses its own internally provided one. All code adjusted to remove old logic (config via a portlet init parameter) and to ensure the internal wrappers worked (as much as they can) in supporting write behind behavior for Myfaces (not) and Mojarra.
> Portlet 2.0 Bridge: Resource as source of iFrame doesn't render in Pluto
> ------------------------------------------------------------------------
>
> Key: PORTLETBRIDGE-162
> URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-162
> Project: MyFaces Portlet Bridge
> Issue Type: Bug
> Components: Impl
> Affects Versions: 2.0.0-beta
> Reporter: Michael Freedman
> Assignee: Michael Freedman
> Fix For: 2.0.0
>
>
> If the resource target for the above is a Face view, the bridge runs through/executesd the normal Faces lifecycle to render the resource. It dispatches to the view JSP using forward. In the regular case (nonResource) this is actually translated by Pluto into a servlet include simulating the forward. However for a resource its an actual servlet forward. Tomcat closes the response and flushes the markup (from it) at the end of the forward. So unless the response is wrapped/buffered Faces can't write after the forward.
> So the solution is to be sure the response is always wrapped/buffered (similar to the base Faces implementation). Do this for all requests (render and resource) as we don't know how the portlet container we are running on may be working
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.