Page History

...

The best way to explain wildcards is to show an example and walk through how it works. This example modifies a conventional mapping to use wildcards to match all pages that start with /edit:

<!-- Generic edit* mapping -->
<action
    name="/edit*"
    class="org.apache.struts.webapp.example.Edit{1}Action">
    <result
        name="failure"
        path=">/mainMenu.jsp"jsp</>result>
    <result
        path="/<result>{1}.jsp"jsp</>result>
</action>

The "*" in the path name attribute allows the mapping to match the request URIs /editSubscription, editRegistration, or any other URI that starts with /edit, however /editSubscription/add would not be matched. The part of the URI matched by the wildcard will then be substituted into various attributes of the action mapping and its action results replacing {1}. For the rest of the request, the framework will see the action mapping and its action results containing the new values.

Mappings are matched against the request in the order they appear in the framework's configuration file. If more than one pattern matches the last one wins, so less specific patterns must appear before more specific ones. However, if the request URL can be matched against a path without any wildcards in it, no wildcard matching is performed and order is not important. Also, note that wildcards are not greedy, meaning they only match until the first occurrence of the following string pattern. For example, consider the following mapping:

...

<action name="/edit/*" class="org.apache.struts.webapp.example.Edit{1}Action">
    <param name="id">{1}</param>
    <result>
   <result   <param name="failure" path="/mainMenu.jsp"/>location">/mainMenu.jsp</param>
      <param name="id">{1}</param> 
    </result>
</action>

See also Wildcard Method

...