[
https://issues.apache.org/jira/browse/TRINIDAD-134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12570449#action_12570449
]
Scott O'Bryan commented on TRINIDAD-134:
----------------------------------------
Ok, I've figured out the other workaround and it seems to work. Essentially,
if we have a portlet request and if the UIViewRoot is the one provided by the
R.I. then we will create a PortletNamingContainerUIViewRoot instead of the one
retrieved from the renderkit. This follow the same logic as the portlet-bridge
and, like the bridge, will expect anything which may override the UIViewRoot
object with their own namespacing.
This introduces a "build time" dependency on the MyFaces Portlet-Bridge but
should not effect runtime unless running in a portlet environment.
> StateManagerImpl is not fully compatible with JSR-301
> -----------------------------------------------------
>
> Key: TRINIDAD-134
> URL: https://issues.apache.org/jira/browse/TRINIDAD-134
> Project: MyFaces Trinidad
> Issue Type: Bug
> Components: Portlet
> Affects Versions: 1.2.1-core
> Environment: JSR-168, JSR-301
> Reporter: Scott O'Bryan
> Assignee: Matthias Weßendorf
> Fix For: 1.2.3-core, 1.2.7-core
>
> Attachments: trinidad-134.patch
>
>
> StateManagerImpl has a performance enhancement that is not compatible with
> JSR-301. Inside of the popRoot method inside of
> org.apache.myfaces.trinidadinternal.application.StateManagerImpl, the view
> root is retrieved using Application.createComponent();. The JSR-301 bridge
> has a special UIViewRoot that, due to limitations in the JSF specification,
> can only reasonably be retrieved through ViewHandler.createViewRoot(). We
> either need to try to try to retrieve the UIViewRoot using this mechanism OR
> we need to disable this performance optimization in a portal environment.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
