Pluto
  1. Pluto
  2. PLUTO-367

Add public render parameters tests to testsuite for JSR-286

    Details

      Description

      A testsuite test needs to be created to test JSR-286 shared render parameters. This is necessary to make sure merging the 1.1-286-COMPATIBILITY branch with the Pluto trunk and any other 1.1-286-COMPATIBILITY branch refactorings does not break this functionality.

        Issue Links

          Activity

          Craig Doremus created issue -
          Craig Doremus made changes -
          Field Original Value New Value
          Link This issue blocks PLUTO-442 [ PLUTO-442 ]
          Hide
          Craig Doremus added a comment -

          Modified title to make it more visible in PLUTO-442 link

          Show
          Craig Doremus added a comment - Modified title to make it more visible in PLUTO-442 link
          Craig Doremus made changes -
          Fix Version/s 1.1-286-trunk-merge [ 12312669 ]
          Affects Version/s 1.1-286-trunk-merge [ 12312669 ]
          Summary Create a testsuite test for JSR-286 shared render parameters. Add public render parameters tests to testsuite for JSR-286
          Hide
          Craig Doremus added a comment -

          In working on these Public Render Parameter tests, I found that line 167 in RelativePortalURLImpl (clearParameters() method) threw a NullPointerException because the window ID was null for public render parameters (the PortalURLParameter.getWindow() call returns null). I stuck a null check there and it worked.

          However I noticed a number of other places where PortalURLParameter.getWindow() id was called and some of them did not have a null check. I can also stick null checks where they are missing, but I want to make sure this does not have unintended consequences. Torsten (or anyone else), can you comment on this?

          BTW, my tests indicate that if a public render parameters is not declared by a supported-public-render-parameter element in a portlet.xml record of a portlet instance, then the portlet window does not see it. This is proper behaviour according to the JSR-286 spec. I will add that check and others to this testsuite test.

          Show
          Craig Doremus added a comment - In working on these Public Render Parameter tests, I found that line 167 in RelativePortalURLImpl (clearParameters() method) threw a NullPointerException because the window ID was null for public render parameters (the PortalURLParameter.getWindow() call returns null). I stuck a null check there and it worked. However I noticed a number of other places where PortalURLParameter.getWindow() id was called and some of them did not have a null check. I can also stick null checks where they are missing, but I want to make sure this does not have unintended consequences. Torsten (or anyone else), can you comment on this? BTW, my tests indicate that if a public render parameters is not declared by a supported-public-render-parameter element in a portlet.xml record of a portlet instance, then the portlet window does not see it. This is proper behaviour according to the JSR-286 spec. I will add that check and others to this testsuite test.
          Hide
          Torsten Dettborn added a comment -

          Hi Craig,
          the PublicRenderParameter isn't bound to a window, so it's right to add the null checks. Thanks for adding the testportlets for the testsuite.

          Show
          Torsten Dettborn added a comment - Hi Craig, the PublicRenderParameter isn't bound to a window, so it's right to add the null checks. Thanks for adding the testportlets for the testsuite.
          Hide
          Craig Doremus added a comment -

          I discovered that when more than one public render parameter is used by a portlet, they all are given null values. This is reported in PLUTO-454. The PLUTO-454 issue should be addressed before the one I previously reported in this issue is addressed.

          For the record, calls to PortalURLParameter.getWindow() are done without null checks in the following methods:
          PortalURLImpl.addParameter()
          PortalURLImpl.clearParameters()
          PortalURLParserImpl.toString() 3 occurrances
          RelativePortalURLImpl.addParameter()
          RelativePortalURLImpl.clearParameters()

          Show
          Craig Doremus added a comment - I discovered that when more than one public render parameter is used by a portlet, they all are given null values. This is reported in PLUTO-454 . The PLUTO-454 issue should be addressed before the one I previously reported in this issue is addressed. For the record, calls to PortalURLParameter.getWindow() are done without null checks in the following methods: PortalURLImpl.addParameter() PortalURLImpl.clearParameters() PortalURLParserImpl.toString() 3 occurrances RelativePortalURLImpl.addParameter() RelativePortalURLImpl.clearParameters()
          Hide
          Craig Doremus added a comment -

          Added checkPublicRenderParameter test to testsuite in SVN rev. 609511. This is the first test in a suite of public render parameter tests that need to be developed.

          Show
          Craig Doremus added a comment - Added checkPublicRenderParameter test to testsuite in SVN rev. 609511. This is the first test in a suite of public render parameter tests that need to be developed.
          Hide
          Ate Douma added a comment -

          Implemented

          Show
          Ate Douma added a comment - Implemented
          Ate Douma made changes -
          Status Open [ 1 ] Resolved [ 5 ]
          Resolution Fixed [ 1 ]
          Mark Thomas made changes -
          Workflow jira [ 12404372 ] Default workflow, editable Closed status [ 12565278 ]
          Mark Thomas made changes -
          Workflow Default workflow, editable Closed status [ 12565278 ] jira [ 12586008 ]
          Gavin made changes -
          Link This issue blocks PLUTO-442 [ PLUTO-442 ]
          Gavin made changes -
          Link This issue is depended upon by PLUTO-442 [ PLUTO-442 ]

            People

            • Assignee:
              Unassigned
              Reporter:
              Craig Doremus
            • Votes:
              1 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development