Struts 2
  1. Struts 2
  2. WW-3784

Greedy and non-greedy matching behaviour should work in action methods using annotated wildcards

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 2.3.1.2
    • Fix Version/s: 2.5
    • Component/s: Core Actions
    • Labels:
      None
    • Environment:

      Win XP, Linux / JDK 7 (Oracle)

      Description

      @Namespace("/do")
      public class CRUDAction {
          /* [1] specific wildcard */
          @Override @Action(value="some/usefull/{stuff}",results={@Result(location = "result.jsp")})
          public String execute() throws Exception {...}
      
          /* [2] less specific wildcard */
          @Override @Action(value="some/{stuff}", results={@Result(location ="result.jsp")})
          public String input() throws Exception {...} 
      }
      

      Currently pattern [2] due to greedy natching catches every "/do/some/{stuff}" AND "/do/some/usefull/{stuff}" event.

      For instance while calling /do/some/eating or /do/some/usefull/sleeping will both end in [2] where stuff becomes "eating" or "usefull/sleep" respectively, [1] is left behind with nothing to do.

      The expected matching behaviour should always be from more specific to less specific.
      I.e. [2] should never fire before [1]. So that /do/some/usefull/sleeping would correctly map to [1] with stuff==sleeping and /do/some/eating correctly maps to [2] with stuff==eating.

      Using xml one can achieve the correct matching order by re-ordering the action definitions (most specific action mapping comes first)

        Activity

        Mo Be created issue -
        Lukasz Lenart made changes -
        Field Original Value New Value
        Fix Version/s 2.3.7 [ 12323448 ]
        Lukasz Lenart made changes -
        Fix Version/s 2.3.8 [ 12323480 ]
        Fix Version/s 2.3.7 [ 12323448 ]
        Lukasz Lenart made changes -
        Fix Version/s 2.3.9 [ 12323841 ]
        Fix Version/s 2.3.8 [ 12323480 ]
        Lukasz Lenart made changes -
        Description @Namespace("/do")
        public class CRUDAction {
         /* [1] specific wildcard */
         @Override @Action(value="some/usefull/{stuff}",results={@Result(location = "result.jsp")})
         public String execute() throws Exception {...}

         /* [2] less specific wildcard */
         @Override @Action(value="some/{stuff}", results={@Result(location ="result.jsp")})
         public String input() throws Exception {...} }

         Currently pattern [2] due to greedy natching catches every "/do/some/{stuff}" AND "/do/some/usefull/{stuff}" event.

         For instance while calling /do/some/eating or /do/some/usefull/sleeping will both end in [2] where stuff becomes "eating" or "usefull/sleep" respectively, [1] is left behind with nothing to do.

         The expected matching behaviour should always be from more specific to less specific.
         I.e. [2] should never fire before [1]. So that /do/some/usefull/sleeping would correctly map to [1] with stuff==sleeping and /do/some/eating correctly maps to [2] with stuff==eating.

         Using xml one can achieve the correct matching order by re-ordering the action definitions (most specific action mapping comes first)

           
        {code:java}
        @Namespace("/do")
        public class CRUDAction {
            /* [1] specific wildcard */
            @Override @Action(value="some/usefull/{stuff}",results={@Result(location = "result.jsp")})
            public String execute() throws Exception {...}

            /* [2] less specific wildcard */
            @Override @Action(value="some/{stuff}", results={@Result(location ="result.jsp")})
            public String input() throws Exception {...}
        }
        {code}

        Currently pattern [2] due to greedy natching catches every "/do/some/{stuff}" AND "/do/some/usefull/{stuff}" event.

        For instance while calling /do/some/eating or /do/some/usefull/sleeping will both end in [2] where stuff becomes "eating" or "usefull/sleep" respectively, [1] is left behind with nothing to do.

        The expected matching behaviour should always be from more specific to less specific.
        I.e. [2] should never fire before [1]. So that /do/some/usefull/sleeping would correctly map to [1] with stuff==sleeping and /do/some/eating correctly maps to [2] with stuff==eating.

        Using xml one can achieve the correct matching order by re-ordering the action definitions (most specific action mapping comes first)

           
        Lukasz Lenart made changes -
        Description {code:java}
        @Namespace("/do")
        public class CRUDAction {
            /* [1] specific wildcard */
            @Override @Action(value="some/usefull/{stuff}",results={@Result(location = "result.jsp")})
            public String execute() throws Exception {...}

            /* [2] less specific wildcard */
            @Override @Action(value="some/{stuff}", results={@Result(location ="result.jsp")})
            public String input() throws Exception {...}
        }
        {code}

        Currently pattern [2] due to greedy natching catches every "/do/some/{stuff}" AND "/do/some/usefull/{stuff}" event.

        For instance while calling /do/some/eating or /do/some/usefull/sleeping will both end in [2] where stuff becomes "eating" or "usefull/sleep" respectively, [1] is left behind with nothing to do.

        The expected matching behaviour should always be from more specific to less specific.
        I.e. [2] should never fire before [1]. So that /do/some/usefull/sleeping would correctly map to [1] with stuff==sleeping and /do/some/eating correctly maps to [2] with stuff==eating.

        Using xml one can achieve the correct matching order by re-ordering the action definitions (most specific action mapping comes first)

           
        {code:java}
        @Namespace("/do")
        public class CRUDAction {
            /* [1] specific wildcard */
            @Override @Action(value="some/usefull/{stuff}",results={@Result(location = "result.jsp")})
            public String execute() throws Exception {...}

            /* [2] less specific wildcard */
            @Override @Action(value="some/{stuff}", results={@Result(location ="result.jsp")})
            public String input() throws Exception {...}
        }
        {code}

        Currently pattern [2] due to greedy natching catches every "/do/some/\{stuff}" AND "/do/some/usefull/\{stuff}" event.

        For instance while calling /do/some/eating or /do/some/usefull/sleeping will both end in [2] where stuff becomes "eating" or "usefull/sleep" respectively, [1] is left behind with nothing to do.

        The expected matching behaviour should always be from more specific to less specific.
        I.e. [2] should never fire before [1]. So that /do/some/usefull/sleeping would correctly map to [1] with stuff==sleeping and /do/some/eating correctly maps to [2] with stuff==eating.

        Using xml one can achieve the correct matching order by re-ordering the action definitions (most specific action mapping comes first)

           
        Lukasz Lenart made changes -
        Fix Version/s 2.3.10 [ 12323903 ]
        Fix Version/s 2.3.9 [ 12323841 ]
        Lukasz Lenart made changes -
        Fix Version/s 2.3.12 [ 12324067 ]
        Fix Version/s 2.3.11 [ 12323903 ]
        Lukasz Lenart made changes -
        Fix Version/s 2.3.13 [ 12324132 ]
        Fix Version/s 2.3.12 [ 12324067 ]
        Lukasz Lenart made changes -
        Fix Version/s 2.3.14 [ 12324256 ]
        Fix Version/s 2.3.13 [ 12324132 ]
        Lukasz Lenart made changes -
        Fix Version/s 2.3.15 [ 12324267 ]
        Fix Version/s 2.3.14 [ 12324256 ]
        Lukasz Lenart made changes -
        Fix Version/s 2.3.16 [ 12324546 ]
        Fix Version/s 2.3.15 [ 12324267 ]
        Lukasz Lenart made changes -
        Fix Version/s 2.3.17 [ 12324780 ]
        Fix Version/s 2.3.16 [ 12324546 ]
        Lukasz Lenart made changes -
        Fix Version/s 2.5 [ 12324447 ]
        Fix Version/s 2.3.17 [ 12324780 ]

          People

          • Assignee:
            Unassigned
            Reporter:
            Mo Be
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:

              Development