Pluto
  1. Pluto
  2. PLUTO-567

Make Pluto work even if main portlets are not available.

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.0.1
    • Component/s: None
    • Labels:
      None

      Description

      Pluto stops when a portlet is not available to the container.

      A small patch will be provided to let the container run even if no portlets are available.

      1. PLUTO-567-patch-cleaned-up.patch
        12 kB
        Ate Douma
      2. PLUTO-567-verbose-output.patch
        11 kB
        Gonzalo Aguilar

        Activity

        Hide
        Ate Douma added a comment -

        Patch committed.
        I only slightly modified it by adding debug logging to the PortletTag try-catch exception handling block.
        Thanks Gonzalo.

        Show
        Ate Douma added a comment - Patch committed. I only slightly modified it by adding debug logging to the PortletTag try-catch exception handling block. Thanks Gonzalo.
        Hide
        Ate Douma added a comment -

        Thanks for the new patch Gonzalo.
        Will review again later this week and apply if feasible.

        Show
        Ate Douma added a comment - Thanks for the new patch Gonzalo. Will review again later this week and apply if feasible.
        Hide
        Gonzalo Aguilar added a comment -

        Created a new version:

        • PortletContainerImpl.java
          >Guarding against a null PortletWindow during (only render!) should not be needed: it is the responsibility of the invoking Portal to >ensure required parameters are provided, otherwise don't call the container. So this change is not OK.
          Yes! You are Right. Not needed. Will take care PortletRenderTag.
        • PortletTag.java
          >Change seems OK to me, except a more descriptive message, like mentioning the portletId for the non-available portlet, should be >provided.
          >Also, strip out the FIXME comment.
          Done, Looks much better
        • PortletModeDropDownTag.java
          >Seems OK too, however the FIXME comment should be replaced with a better description why the exception is ignored.
          Done
        • PortletTitleTag.java
          Looks OK, maybe replace "[Unknown]" with "[Unknown - "+parentTag.getPortletId()+"]"
          > Done
        Show
        Gonzalo Aguilar added a comment - Created a new version: PortletContainerImpl.java >Guarding against a null PortletWindow during (only render!) should not be needed: it is the responsibility of the invoking Portal to >ensure required parameters are provided, otherwise don't call the container. So this change is not OK. Yes! You are Right. Not needed. Will take care PortletRenderTag. PortletTag.java >Change seems OK to me, except a more descriptive message, like mentioning the portletId for the non-available portlet, should be >provided. >Also, strip out the FIXME comment. Done, Looks much better PortletModeDropDownTag.java >Seems OK too, however the FIXME comment should be replaced with a better description why the exception is ignored. Done PortletTitleTag.java Looks OK, maybe replace " [Unknown] " with " [Unknown - "+parentTag.getPortletId()+"] " > Done
        Hide
        Gonzalo Aguilar added a comment -

        Hi Ate

        I'm sorry. I cannot use svn because eclipse updated repository to a newer version than I have. So I have to stick with Eclipse svn capabilities. I will recheck how to do it right.

        I will upgrade this with the comments you sent me and resend a clean patch.

        Thanks again.

        Show
        Gonzalo Aguilar added a comment - Hi Ate I'm sorry. I cannot use svn because eclipse updated repository to a newer version than I have. So I have to stick with Eclipse svn capabilities. I will recheck how to do it right. I will upgrade this with the comments you sent me and resend a clean patch. Thanks again.
        Hide
        Ate Douma added a comment -

        Hi Gonzalo,

        First of all, please make sure to provide easily apply able and clean patches.
        Your patch seemed to be a hand-merged set of patches into a single file, for different svn root folders.
        As result, I had to break it up again myself first.
        Furthermore, having unrelated (like the one for PLUTO-565) or unneeded changes mixed in really is bad practice.

        As reference I'm attaching a new clean patch file with only the relevant changes for this issue, created using "$svn diff > PLUTO-567-patch-cleaned-up.patch" from the root folder.

        About your proposed changes:

        First of all, I haven't tested these out, so this is only a preliminary review.

        • PortletContainerImpl.java
          Guarding against a null PortletWindow during (only render!) should not be needed: it is the responsibility of the invoking Portal to ensure required parameters are provided, otherwise don't call the container. So this change is not OK.
        • PortletTag.java
          Change seems OK to me, except a more descriptive message, like mentioning the portletId for the non-available portlet, should be provided.
          Also, strip out the FIXME comment.
        • PortletModeDropDownTag.java
          Seems OK too, however the FIXME comment should be replaced with a better description why the exception is ignored.
        • PortletTitleTag.java
          Looks OK, maybe replace "[Unknown]" with "[Unknown - "+parentTag.getPortletId()+"]"
        Show
        Ate Douma added a comment - Hi Gonzalo, First of all, please make sure to provide easily apply able and clean patches. Your patch seemed to be a hand-merged set of patches into a single file, for different svn root folders. As result, I had to break it up again myself first. Furthermore, having unrelated (like the one for PLUTO-565 ) or unneeded changes mixed in really is bad practice. As reference I'm attaching a new clean patch file with only the relevant changes for this issue, created using "$svn diff > PLUTO-567 -patch-cleaned-up.patch" from the root folder. About your proposed changes: First of all, I haven't tested these out, so this is only a preliminary review. PortletContainerImpl.java Guarding against a null PortletWindow during (only render!) should not be needed: it is the responsibility of the invoking Portal to ensure required parameters are provided, otherwise don't call the container. So this change is not OK. PortletTag.java Change seems OK to me, except a more descriptive message, like mentioning the portletId for the non-available portlet, should be provided. Also, strip out the FIXME comment. PortletModeDropDownTag.java Seems OK too, however the FIXME comment should be replaced with a better description why the exception is ignored. PortletTitleTag.java Looks OK, maybe replace " [Unknown] " with " [Unknown - "+parentTag.getPortletId()+"] "
        Hide
        Gonzalo Aguilar added a comment -

        This patch makes the portlet container show something when the portlet is not available.

        NOTE: This also includes the config patch of PLUTO-565 issue.

        Show
        Gonzalo Aguilar added a comment - This patch makes the portlet container show something when the portlet is not available. NOTE: This also includes the config patch of PLUTO-565 issue.

          People

          • Assignee:
            Ate Douma
            Reporter:
            Gonzalo Aguilar
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Time Tracking

              Estimated:
              Original Estimate - 1h
              1h
              Remaining:
              Remaining Estimate - 1h
              1h
              Logged:
              Time Spent - Not Specified
              Not Specified

                Development