Uploaded image for project: 'Pluto'
  1. Pluto
  2. PLUTO-499

Invoking FilterConfig.getInitParameter() when there are no filter parameters defined results in NPE

        Details

        • Type: Bug
        • Status: Resolved
        • Priority: Major
        • Resolution: Fixed
        • Affects Version/s: 2.0-refactoring, 2.0.0
        • Fix Version/s: 2.0-refactoring, 2.0.0
        • Component/s: portlet container
        • Labels:
          None
        • Environment:
          JDK 1.5.0_16, Tomcat 5.5.27

          Description

          Within the init() method of a PortletFilter, if you invoke the GetInitParameter() method of the passed-in FilterConfig object a NullPointerException is thrown if the filter has been configured with NO initialization parameters. The NPE comes from

          org.apache.pluto.driver.services.container.FilterConfigImpl.getInitParameter(FilterConfigImpl.java:48)

          If you configure the portlet filter with ANY initiailization parameters the NPE is avoided.

          According to the JSR286 spec it seems that any call to GetInitParameter() that references a non-existent initialization parameter should return null.

          1. Java Source File
            FilterConfigImpl.java
            2 kB
            Brian DeHamer
          2. Text File
            Pluto_499.patch
            0.9 kB
            Craig Doremus

            Activity

            Ascending order - Click to sort in descending order
            Hide
            Permalink
            bdehamer Brian DeHamer added a comment -

            Attached is an updated copy of FilterConfigImpl which includes a null check in the getInitParameters method. This appears to solve the problem

            Show
            bdehamer Brian DeHamer added a comment - Attached is an updated copy of FilterConfigImpl which includes a null check in the getInitParameters method. This appears to solve the problem
            Hide
            Permalink
            cdoremus Craig Doremus added a comment -

            Thank you, Brian, for debugging this issue. I created a patch file based on your input. I will try to apply it soon if someone else doesn't beat me to it.

            Show
            cdoremus Craig Doremus added a comment - Thank you, Brian, for debugging this issue. I created a patch file based on your input. I will try to apply it soon if someone else doesn't beat me to it.
            Hide
            Permalink
            cdoremus Craig Doremus added a comment -

            The patch should be applied to the trunk and the 2.0-refactoring branch.

            Show
            cdoremus Craig Doremus added a comment - The patch should be applied to the trunk and the 2.0-refactoring branch.
            Hide
            Permalink
            cdoremus Craig Doremus added a comment -

            Applied fix contributed by Brian DeHamer to trunk and 2.0-refactoring branch in SVN revs 701590 and 701593.

            Show
            cdoremus Craig Doremus added a comment - Applied fix contributed by Brian DeHamer to trunk and 2.0-refactoring branch in SVN revs 701590 and 701593.

              People

              • Assignee:
                Unassigned
                Reporter:
                bdehamer Brian DeHamer
              • Votes:
                0 Vote for this issue
                Watchers:
                0 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:

                  Development