MyFaces Portlet Bridge
  1. MyFaces Portlet Bridge
  2. PORTLETBRIDGE-47

BridgeImpl pass PortletConfig instance to FacesContextFactory instead PortletContext

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 1.0.0-alpha-2
    • Fix Version/s: 1.0.0-beta, 2.0.0-alpha
    • Component/s: None
    • Labels:
      None

      Description

      On myfaces portlet bridge (for jsf 1.2) do this (org.apache.myfaces.portlet.faces.bridge.BridgeImpl line 240):

      try
      {
      // Get the FacesContext instance for this request
      context =
      getFacesContextFactory().getFacesContext(mPortletConfig, request, response, getLifecycle());

      It should pass a javax.portlet.PortletContext instance instead, because this is the expected var here.

        Issue Links

          Activity

          Hide
          Michael Freedman added a comment -

          bridge has been modified to pass/ really on the PortletContext to the FacesContextFactory vs the PortletConfig.

          Show
          Michael Freedman added a comment - bridge has been modified to pass/ really on the PortletContext to the FacesContextFactory vs the PortletConfig.
          Hide
          Scott O'Bryan added a comment -

          This won't effect Trinidad or Commons. We made this assumption but we always retrieve any context we use from the ExternalContext. In this case, Tomahawk needs to be able to do this from a servlet environment. I wrote a note to the EG about this issue and will hopefully have an answer soon. I think it's reasonable to expect a context object here and, if we can't provide one, we need the spec to clearly define that we will receive a config.

          The R.I. will of course be updated accordingly, so I'm going to keep this bug open for now until we get final word.

          Show
          Scott O'Bryan added a comment - This won't effect Trinidad or Commons. We made this assumption but we always retrieve any context we use from the ExternalContext. In this case, Tomahawk needs to be able to do this from a servlet environment. I wrote a note to the EG about this issue and will hopefully have an answer soon. I think it's reasonable to expect a context object here and, if we can't provide one, we need the spec to clearly define that we will receive a config. The R.I. will of course be updated accordingly, so I'm going to keep this bug open for now until we get final word.
          Hide
          Scott O'Bryan added a comment -

          Yeah, I think we may need to update something on the spec here. Although the JSF specification does not SAY this has to be a PortletContext, it does at least infer IMO that we are expecting a context object and not a config object.

          As such, I would say that in order to be compatible with legacy bridges and avoid a ton of confusion - not to mention save me a bunch of work on Trinidad, commons, etc. then we should adjust the spec to set this prefix up in the GenericPortlet prior to calling the bridge. OR we should have some other way to reference it.

          I'll bring this up to the EG and get a verdict. Thanks for catching this..

          Show
          Scott O'Bryan added a comment - Yeah, I think we may need to update something on the spec here. Although the JSF specification does not SAY this has to be a PortletContext, it does at least infer IMO that we are expecting a context object and not a config object. As such, I would say that in order to be compatible with legacy bridges and avoid a ton of confusion - not to mention save me a bunch of work on Trinidad, commons, etc. then we should adjust the spec to set this prefix up in the GenericPortlet prior to calling the bridge. OR we should have some other way to reference it. I'll bring this up to the EG and get a verdict. Thanks for catching this..
          Hide
          Leonardo Uribe added a comment -

          Entering into details, the reason why a PortletConfig instance is passed to PortletExternalContextImpl is that for calculate the viewId it does this (in some part of private String getViewId(boolean updateHistory):

          if (viewId == null)
          {
          Map<String, String> m = (Map<String,String>) mPortletContext.getAttribute(
          Bridge.BRIDGE_PACKAGE_PREFIX + mPortletConfig.getPortletName()
          + "." + Bridge.DEFAULT_VIEWID_MAP);
          viewId = m.get(requestedMode);
          if (viewId == null)

          { // If no defaultview then throw an exception throw new BridgeDefaultViewNotSpecifiedException(); }

          log("PortletExternalContextImpl.getViewId: jsf target viewId not found, defaulting to: " + viewId);
          }

          it uses the portlet name to build the id. I don't know how to get a PortletConfig instance based on a PortletContext or obtain the portlet name.

          In the doc of getPortletName it says

          "...The name may be provided via server administration, assigned in the portlet application deployment descriptor with the portlet-name tag...."

          I hope this help.

          Show
          Leonardo Uribe added a comment - Entering into details, the reason why a PortletConfig instance is passed to PortletExternalContextImpl is that for calculate the viewId it does this (in some part of private String getViewId(boolean updateHistory): if (viewId == null) { Map<String, String> m = (Map<String,String>) mPortletContext.getAttribute( Bridge.BRIDGE_PACKAGE_PREFIX + mPortletConfig.getPortletName() + "." + Bridge.DEFAULT_VIEWID_MAP); viewId = m.get(requestedMode); if (viewId == null) { // If no defaultview then throw an exception throw new BridgeDefaultViewNotSpecifiedException(); } log("PortletExternalContextImpl.getViewId: jsf target viewId not found, defaulting to: " + viewId); } it uses the portlet name to build the id. I don't know how to get a PortletConfig instance based on a PortletContext or obtain the portlet name. In the doc of getPortletName it says "...The name may be provided via server administration, assigned in the portlet application deployment descriptor with the portlet-name tag...." I hope this help.

            People

            • Assignee:
              Michael Freedman
              Reporter:
              Leonardo Uribe
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development