[jira] Commented: (PB-35) Multiple instances of the same bridge application behave badly due to ID conflicts

["Matthew Bruzek (JIRA)" <br...@portals.apache.org>]

    [ https://issues.apache.org/jira/browse/PB-35?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12472475 ] 

Matthew Bruzek commented on PB-35:
----------------------------------

The UIViewRoot is not a NamingContainer and does not make unique client ids.  This problem can be overcome by creating a class that is a naming container and creates unique names for components.

I have attached an example of my suggestion a new class, UIPortletViewRoot to this comment.

The code in the jsf portlet bridge would have to create a UIPortletViewRoot in places where it constructed new UIViewRoot objects.  My research suggests the classes FacesPortlet and PortletFacesContextImpl would likely need to change the way the create UIViewRoot objects.

In the FacesPortlet class the method that creates UIViewRoot objects is setDefaultView().  The code creates a UIViewRoot if the viewRoot is null for a RenderRequest.  You could create a UIPortletViewRoot instead.  It may be wise to duplicate this code if viewRoot is null for ActionRequests (we do not ever want the viewRoot to ever be null).

In the PortletFacesContextImpl class the method that creates UIViewRoot objects is resolveViewRoot().  The application ViewHandler creates a UIViewRoot if the viewRoot is null.  This code could pass the newly created ViewRoot to the convenience constructor of UIPortletViewRoot.



> Multiple instances of the same bridge application behave badly due to ID conflicts
> ----------------------------------------------------------------------------------
>
>                 Key: PB-35
>                 URL: https://issues.apache.org/jira/browse/PB-35
>             Project: Portals Bridges
>          Issue Type: Bug
>          Components: jsf
>         Environment: Tested in Liferay
>            Reporter: russ danner
>         Assigned To: David Sean Taylor
>
> I am using the myFaces implementation of JSF in conjunction with the Apache portal bridge.  
> I have no issue when I use the portlet as a single instance. All is beautiful. When I make the portlet multi-instance the eorld comes tumbling down. All the javascript and component ID's are the same.
> --
> I know myfaces looks to the external context to call help create a unique id for the components which should call response.namespace();
> You can see in the HTML output of the lifray install that unqiue names are being generated for the each portlet (both the same "flavor")
> portlet [com.liferay.portlet.PortletSessionImpl@608486] namespace response[_contentRepositoryBrowser-wide_WAR_contentRepositoryBrowser_INSTANCE_Ju5n_]
> portlet [com.liferay.portlet.PortletSessionImpl@1919998] namespace response[_contentRepositoryBrowser-wide_WAR_contentRepositoryBrowser_INSTANCE_1cKB_]
> I know myFaces makes the following call on create unique Id:
>    public String createUniqueId()
>    {
>         ExternalContext extCtx = FacesContext.getCurrentInstance().getExternalContext();
>         return extCtx.encodeNamespace(UNIQUE_ID_PREFIX + _uniqueIdCounter++);
>     }
> which in the end should pickup the names given by RenderResponse.getNamespace(), yet that is no where in the HTML output.  
> As far as I can tell this is because the external context implementation provided with the apache jsf portlet bridge does the following:
>     /**
>      * @see javax.faces.context.ExternalContext#encodeNamespace(java.lang.String)
>      */
>     public String encodeNamespace(String s)
>     {
>         return s;
>     }
> according to the documentation for ExternalContext.encodeNamespace(..)
> Return the specified name, after prefixing it with a namespace that ensures that it will be unique within the context of a particular page.
> Servlet: The input value must be returned unchanged.
> Portlet: The returned value must be the input value prefixed by the value returned by the javax.portlet.RenderResponse method getNamespace().

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: bridges-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: bridges-dev-help@portals.apache.org