Tiles
  1. Tiles
  2. TILES-134

NullPointer Exception when tiles servlet is not defined

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.0.2
    • Fix Version/s: 2.0.2
    • Labels:
      None
    • Environment:

      Tomcat 5.5.20, jre1.5_06

    • Flags:
      Patch

      Description

      When implementing a simple template and the tiles servlet is not defined in the web.xml you get a NullPointer exception at line 144 when running. This can be difficult for the implementer to realize what they did wrong. A suggestion would be to throw and exception when the context is null. It might be better to throw a TilesException however the interface defines a JspException so I used it.

      — RenderTagSupport.java 2007-03-05 16:53:50.000000000 -0500
      +++ tiles-jsp/src/main/java/org/apache/tiles/jsp/taglib/RenderTagSupport.java 2007-03-05 16:52:49.000000000 -0500
      @@ -136,13 +136,11 @@
      *

      • @param nestedTag the put tag desciendent.
        */
      • public void processNestedTag(PutAttributeTag nestedTag) throws JspException {
        + public void processNestedTag(PutAttributeTag nestedTag) {
        ComponentAttribute attribute = new ComponentAttribute(
        nestedTag.getValue(), nestedTag.getRole(),
        nestedTag.getType());
      • if (componentContext==null) throw new JspException("componentContext is null. Do you have the org.apache.tiles.servlet.TilesServlet defined in the web.xml?");
        -
        componentContext.putAttribute(
        nestedTag.getName(),
        attribute
        ~

        Issue Links

          Activity

          Hide
          Antonio Petrelli added a comment -

          Issue resolved by throwing a JspException in ContainerTagSupport.doStartTag when no container has been found.

          Show
          Antonio Petrelli added a comment - Issue resolved by throwing a JspException in ContainerTagSupport.doStartTag when no container has been found.
          Hide
          Antonio Petrelli added a comment -

          The container can be (currently) initialized through the use of TilesServlet, TilesListener or the <tiles:initContainer> tag.

          Show
          Antonio Petrelli added a comment - The container can be (currently) initialized through the use of TilesServlet, TilesListener or the <tiles:initContainer> tag.
          Hide
          Scot Meyer added a comment -

          At first glance it looks good. I will dl and recompile and check it out, later. Is there anticipation that the container would be initialized potentially outside the tiles servlet? i will document this if that is the case. I would think though in most cases the TilesServlet is the way to go.

          Show
          Scot Meyer added a comment - At first glance it looks good. I will dl and recompile and check it out, later. Is there anticipation that the container would be initialized potentially outside the tiles servlet? i will document this if that is the case. I would think though in most cases the TilesServlet is the way to go.
          Hide
          Antonio Petrelli added a comment -

          Scot wrote:

          Honestly without completly inspecting the code I assumed that there was good reason for container being null in startContext and it appeared that the componentContext was only initially retrieved from the container at this point. So perhaps its really a check of the componentContext validity after the if in the startContext although putting it in doStartTag would effectively be the same assuming you checked after the startContext method call.

          Well, in fact you're right, because attribute tags extend(ed) ContainerTagSupport, though they really don't need them (they interact only with parent tags), see TILES-135
          In the remaining tags (the Insert***Tag classes) the container is essential to work (at least they need to use the correct ComponentContext).
          I committed some code (very different from the one you posted, sorry) that throws a JspException in ContainerTagSupport.doStartTag when a container is not found.

          Thanks a lot anyway, your effort was not thrown away! And go on inspecting code, every help is welcome

          Let me know if it fits your needs, so I will resolve this issue.

          Antonio

          Show
          Antonio Petrelli added a comment - Scot wrote: — Honestly without completly inspecting the code I assumed that there was good reason for container being null in startContext and it appeared that the componentContext was only initially retrieved from the container at this point. So perhaps its really a check of the componentContext validity after the if in the startContext although putting it in doStartTag would effectively be the same assuming you checked after the startContext method call. — Well, in fact you're right, because attribute tags extend(ed) ContainerTagSupport, though they really don't need them (they interact only with parent tags), see TILES-135 In the remaining tags (the Insert***Tag classes) the container is essential to work (at least they need to use the correct ComponentContext). I committed some code (very different from the one you posted, sorry) that throws a JspException in ContainerTagSupport.doStartTag when a container is not found. Thanks a lot anyway, your effort was not thrown away! And go on inspecting code, every help is welcome Let me know if it fits your needs, so I will resolve this issue. Antonio
          Hide
          Antonio Petrelli added a comment -

          Whoops! sorry, it does affect 2.0.2 version.

          Show
          Antonio Petrelli added a comment - Whoops! sorry, it does affect 2.0.2 version.
          Hide
          Scot Meyer added a comment -

          Honestly without completly inspecting the code I assumed that there was good reason for container being null in startContext and it appeared that the componentContext was only initially retrieved from the container at this point. So perhaps its really a check of the componentContext validity after the if in the startContext although putting it in doStartTag would effectively be the same assuming you checked after the startContext method call.

          Show
          Scot Meyer added a comment - Honestly without completly inspecting the code I assumed that there was good reason for container being null in startContext and it appeared that the componentContext was only initially retrieved from the container at this point. So perhaps its really a check of the componentContext validity after the if in the startContext although putting it in doStartTag would effectively be the same assuming you checked after the startContext method call.
          Hide
          Antonio Petrelli added a comment -

          I think you opened a Pandora's vase!
          In fact when a TilesContainer is not present (by not using TilesServlet or other means of container initialization), everything will fail.
          Anyway I think that your proposed patch is not enough, I think that throwing a JspException in ContainerTagSupport.doStartTag when a container is not found is a better solution.

          Thoughts?

          Show
          Antonio Petrelli added a comment - I think you opened a Pandora's vase! In fact when a TilesContainer is not present (by not using TilesServlet or other means of container initialization), everything will fail. Anyway I think that your proposed patch is not enough, I think that throwing a JspException in ContainerTagSupport.doStartTag when a container is not found is a better solution. Thoughts?

            People

            • Assignee:
              Antonio Petrelli
              Reporter:
              Scot Meyer
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development