[ https://issues.apache.org/jira/browse/WW-3784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Lukasz Lenart updated WW-3784: ------------------------------ 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) was: @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) > Greedy and non-greedy matching behaviour should work in action methods using > annotated wildcards > ------------------------------------------------------------------------------------------------- > > Key: WW-3784 > URL: https://issues.apache.org/jira/browse/WW-3784 > Project: Struts 2 > Issue Type: Bug > Components: Core Actions > Affects Versions: 2.3.1.2 > Environment: Win XP, Linux / JDK 7 (Oracle) > Reporter: Mo Be > Fix For: 2.3.9 > > > {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) > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira