Struts2是Struts社區和WebWork社區的共同成果，我們甚至可以說，Struts2是WebWork的升級版，他采用的正是WebWork的核心，所以，Struts2並不是一個不成熟的產品，相反，構建在WebWork基礎之上的Struts2是一個運行穩定、性能優異、設計成熟的WEB框架。
我這里的struts2源碼是從官網下載的一個最新的struts-2.3.15.1-src.zip，將其解壓即可。里面的目錄頁文件非常的多，我們只需要定位到struts-2.3.15.1\src\core\src\main\java\org\apache\struts2查看源文件。目錄結構如下圖
Struts2框架的正常運行，除了占核心地位的xwork的支持以外，Struts2本身也提供了許多類，這些類被分門別類組織到不同的包中。從源代碼中發現，基本上每一個Struts2類都訪問了WebWork提供的功能，從而也可以看出Struts2與WebWork千絲萬縷的聯系。但無論如何，Struts2的核心功能比如將請求委托給哪個Action處理都是由xwork完成的，Struts2只是在WebWork的基礎上做了適當的簡化、加強和封裝，並少量保留Struts1.x中的習慣。
以下是包說明：
| org.apache.struts2. components | 該包封裝視圖組件，Struts2在視圖組件上有了很大加強，不僅增加了組件的屬性個數，更新增了幾個非常有用的組件，如updownselect、doubleselect、datetimepicker、token、tree等。 另外，Struts2可視化視圖組件開始支持主題(theme)，缺省情況下，使用自帶的缺省主題，如果要自定義頁面效果，需要將組件的theme屬性設置為simple。 |
| org.apache.struts2. config | 該包定義與配置相關的接口和類。實際上，工程中的xml和properties文件的讀取和解析都是由WebWork完成的，Struts只做了少量的工作。 |
| org.apache.struts2.dispatcher | Struts2的核心包，最重要的類都放在該包中。 |
| org.apache.struts2.impl | 該包只定義了3個類，他們是StrutsActionProxy、StrutsActionProxyFactory、StrutsObjectFactory，這三個類都是對xwork的擴展。 |
| org.apache.struts2.interceptor | 定義內置的截攔器。 |
| org.apache.struts2.servlet | 用HttpServletRequest相關方法實現principalproxy接口。 |
| org.apache.struts2.util | 實用包。 |
| org.apache.struts2.views | 提供freemarker、jsp、velocity等不同類型的頁面呈現。 |
根目錄下的5個文件說明：
| StrutsStatics | Struts常數。常數可以用來獲取或設置對象從行動中或其他集合。 |
| RequestUtils | 請求處理程序類。此類只有一個方法getServletPath，作用檢索當前請求的servlet路徑 |
| ServletActionContext | 網站的特定的上下文信息 |
| StrutsConstants | 該類提供了框架配置鍵的中心位置用於存儲和檢索配置設置。 |
| StrutsException | 通用運行時異常類 |
struts2 架構圖如下圖所示：
依照上圖，我們可以看出一個請求在struts的處理大概有如下步驟：
1、客戶端初始化一個指向Servlet容器（例如Tomcat）的請求httpservletrequest，容器接收到一個httprequest;
2、servlet容器將請求傳遞給一個標准的過濾器鏈(Filter)（這些過濾器中有一個叫做ActionContextCleanUp的可選過濾器，這個過濾器對於Struts2和其他框架的集成很有幫助，例如：SiteMesh Plugin）;
3、 接着StrutsPrepareAndExecuteFilter被調用，StrutsPrepareAndExecuteFilter詢問ActionMapper來決定這個請求是否需要調用某個Action;
4、如果ActionMapper決定需要調用某個Action，FilterDispatcher把請求的處理交給ActionProxy;
5、ActionProxy將會通過ConfigurationManager來詢問框架的配置文件(struts.xml );
i. ActionProxy創建一個ActionInvocation的實例,通過ActionInvocation來負責命令模式的實現（包括調用一些攔截Interceptor框架在調用action之前）
ii. Interceptor做一些攔截或者初始的工作
6、 一旦action返回，會查找相應的Result
7、Result類型可以是 json、jsp或者freeMark 等
8、這些組件和ActionMapper一起返回給請求的url（注意攔截器的執行順序）
9、響應的返回是通過我們在web.xml中配置的過濾器
10、如果ActionContextCleanUp是當前使用的，則FilterDispatecher將不會清理sreadlocal ActionContext;如果ActionContextCleanUp不使用，則將會去清理sreadlocals。
攔截器與過濾器的區別：
1、攔截器是基於java反射機制的，而過濾器是基於函數回調的。
2、過濾器依賴於servlet容器，而攔截器不依賴於servlet容器。
3、攔截器只能對Action請求起作用，而過濾器則可以對幾乎所有請求起作用。
4、攔截器可以訪問Action上下文、值棧里的對象，而過濾器不能。
5、在Action的生命周期中，攔截器可以多次調用，而過濾器只能在容器初始化時被調用一次。
strut2源碼分析：
首先我們使用struts2框架都會在web.xml中注冊和映射struts2，配置內容如下：
1 <filter> 2 <filter-name>struts2</filter-name> 3 <filter-class>org.apache.struts2.dispatcher.ng.filter.StrutsPrepareAndExecuteFilter</filter-class> 4 </filter> 5 <filter-mapping> 6 <filter-name>struts2</filter-name> 7 <url-pattern>/*</url-pattern> 8 </filter-mapping>
注：在早期的struts2中，都是使用FilterDispathcer，從Struts 2.1.3開始，它已不推薦使用。如果你使用的Struts的版本 >= 2.1.3，推薦升級到新的Filter，StrutsPrepareAndExecuteFilter。在此研究的是StrutsPrepareAndExecuteFilter。
StrutsPrepareAndExecuteFilter中的方法：
| void init(FilterConfig filterConfig) | 繼承自Filter，過濾器的初始化 |
| doFilter(ServletRequest req, ServletResponse res, FilterChain chain) | 繼承自Filter，執行過濾器 |
| void destroy() | 繼承自Filter，用於資源釋放 |
| void postInit(Dispatcher dispatcher, FilterConfig filterConfig) | Callback for post initialization（一個空的方法，用於方法回調初始化） |
web容器一啟動，就會初始化核心過濾器StrutsPrepareAndExecuteFilter，並執行初始化方法，初始化方法如下：
1 public void init(FilterConfig filterConfig) throws ServletException {
2 InitOperations init = new InitOperations();
3 Dispatcher dispatcher = null;
4 try {
5 //封裝filterConfig，其中有個主要方法getInitParameterNames將參數名字以String格式存儲在List中
6 FilterHostConfig config = new FilterHostConfig(filterConfig);
7 //初始化struts內部日志
8 init.initLogging(config);
9 //創建dispatcher ，並初始化
10 dispatcher = init.initDispatcher(config);
11 init.initStaticContentLoader(config, dispatcher);
12 //初始化類屬性：prepare 、execute
13 prepare = new PrepareOperations(filterConfig.getServletContext(), dispatcher);
14 execute = new ExecuteOperations(filterConfig.getServletContext(), dispatcher);
15 this.excludedPatterns = init.buildExcludedPatternsList(dispatcher);
16 //回調空的postInit方法
17 postInit(dispatcher, filterConfig);
18 } finally {
19 if (dispatcher != null) {
20 dispatcher.cleanUpAfterInit();
21 }
22 init.cleanup();
23 }
24 }
關於封裝filterConfig，首先看下FilterHostConfig ，源碼如下：
1 public class FilterHostConfig implements HostConfig {
2
3 private FilterConfig config;
4 //構造方法
5 public FilterHostConfig(FilterConfig config) {
6 this.config = config;
7 }
8 //根據init-param配置的param-name獲取param-value的值
9 public String getInitParameter(String key) {
10 return config.getInitParameter(key);
11 }
12 //返回初始化參數名的迭代器
13 public Iterator<String> getInitParameterNames() {
14 return MakeIterator.convert(config.getInitParameterNames());
15 }
16 //返回Servlet上下文
17 public ServletContext getServletContext() {
18 return config.getServletContext();
19 }
20 }
只有短短的幾行代碼，getInitParameterNames是這個類的核心，將Filter初始化參數名稱有枚舉類型轉為Iterator。此類的主要作為是對filterConfig 封裝。
接下來，看下StrutsPrepareAndExecuteFilter中init方法中dispatcher = init.initDispatcher(config);這是初始化dispatcher的，是通過init對象的initDispatcher方法來初始化的，init是InitOperations類的對象，我們看看InitOperations中initDispatcher方法：
1 public Dispatcher initDispatcher( HostConfig filterConfig ) {
2 Dispatcher dispatcher = createDispatcher(filterConfig);
3 dispatcher.init();
4 return dispatcher;
5 }
創建Dispatcher，會讀取 filterConfig 中的配置信息，將配置信息解析出來，封裝成為一個Map，然后根絕servlet上下文和參數Map構造Dispatcher ：
1 private Dispatcher createDispatcher( HostConfig filterConfig ) {
2 //存放參數的Map
3 Map<String, String> params = new HashMap<String, String>();
4 //將參數存放到Map
5 for ( Iterator e = filterConfig.getInitParameterNames(); e.hasNext(); ) {
6 String name = (String) e.next();
7 String value = filterConfig.getInitParameter(name);
8 params.put(name, value);
9 }
10 //根據servlet上下文和參數Map構造Dispatcher
11 return new Dispatcher(filterConfig.getServletContext(), params);
12 }
這樣dispatcher對象創建完成，接着就是dispatcher對象的初始化，打開Dispatcher類，看到它的init方法如下：
1 public void init() {
2
3 if (configurationManager == null) {
4 configurationManager = createConfigurationManager(BeanSelectionProvider.DEFAULT_BEAN_NAME);
5 }
6
7 try {
8 init_FileManager();
9 //加載org/apache/struts2/default.properties
10 init_DefaultProperties(); // [1]
11 //加載struts-default.xml,struts-plugin.xml,struts.xml
12 init_TraditionalXmlConfigurations(); // [2]
13 init_LegacyStrutsProperties(); // [3]
14 //用戶自己實現的ConfigurationProviders類
15 init_CustomConfigurationProviders(); // [5]
16 //Filter的初始化參數
17 init_FilterInitParameters() ; // [6]
18 init_AliasStandardObjects() ; // [7]
19
20 Container container = init_PreloadConfiguration();
21 container.inject(this);
22 init_CheckWebLogicWorkaround(container);
23
24 if (!dispatcherListeners.isEmpty()) {
25 for (DispatcherListener l : dispatcherListeners) {
26 l.dispatcherInitialized(this);
27 }
28 }
29 } catch (Exception ex) {
30 if (LOG.isErrorEnabled())
31 LOG.error("Dispatcher initialization failed", ex);
32 throw new StrutsException(ex);
33 }
34 }
這里主要是加載一些配置文件的，將按照順序逐一加載：default.properties，struts-default.xml,struts-plugin.xml,struts.xml，……關於文件是如何加載的，大家可以自己取看源文件，主要是由xwork核心類加載的，代碼在xwork-core\src\main\java\com\opensymphony\xwork2\config\providers包里面。
現在，我們回到StrutsPrepareAndExecuteFilter類中，剛才我們分析了StrutsPrepareAndExecuteFilter類的init方法，該方法在web容器一啟動就會調用的，當用戶訪問某個action的時候，首先調用核心過濾器StrutsPrepareAndExecuteFilter的doFilter方法，該方法內容如下：
1 public void doFilter(ServletRequest req, ServletResponse res, FilterChain chain) throws IOException, ServletException {
2
3 HttpServletRequest request = (HttpServletRequest) req;
4 HttpServletResponse response = (HttpServletResponse) res;
5
6 try {
7 //設置編碼和國際化
8 prepare.setEncodingAndLocale(request, response);
9 //創建action上下文
10 prepare.createActionContext(request, response);
11 prepare.assignDispatcherToThread();
12 if (excludedPatterns != null && prepare.isUrlExcluded(request, excludedPatterns)) {
13 chain.doFilter(request, response);
14 } else {
15 request = prepare.wrapRequest(request);
16 ActionMapping mapping = prepare.findActionMapping(request, response, true);
17 //如果mapping為空，則認為不是調用action,會調用下一個過濾器鏈，直到獲取到mapping才調用action
18 if (mapping == null) {
19 boolean handled = execute.executeStaticResourceRequest(request, response);
20 if (!handled) {
21 chain.doFilter(request, response);
22 }
23 } else {
24 //執行action
25 execute.executeAction(request, response, mapping);
26 }
27 }
28 } finally {
29 prepare.cleanupRequest(request);
30 }
31 }
下面對doFilter方法中的重點部分一一講解：
(1)prepare.setEncodingAndLocale(request, response);
第8行是調用prepare對象的setEncodingAndLocale方法，prepare是PrepareOperations類的對象，PrepareOperations類是用來做請求准備工作的。我們看下PrepareOperations類中的setEncodingAndLocale方法：
1 public void setEncodingAndLocale(HttpServletRequest request, HttpServletResponse response) {
2 dispatcher.prepare(request, response);
3 }
在這方法里面我們可以看到它只是調用了dispatcher的prepare方法而已，下面我們看看dispatcher的prepare方法：
1 public void prepare(HttpServletRequest request, HttpServletResponse response) {
2 String encoding = null;
3 if (defaultEncoding != null) {
4 encoding = defaultEncoding;
5 }
6 // check for Ajax request to use UTF-8 encoding strictly http://www.w3.org/TR/XMLHttpRequest/#the-send-method
7 if ("XMLHttpRequest".equals(request.getHeader("X-Requested-With"))) {
8 encoding = "UTF-8";
9 }
10
11 Locale locale = null;
12 if (defaultLocale != null) {
13 locale = LocalizedTextUtil.localeFromString(defaultLocale, request.getLocale());
14 }
15
16 if (encoding != null) {
17 applyEncoding(request, encoding);
18 }
19
20 if (locale != null) {
21 response.setLocale(locale);
22 }
23
24 if (paramsWorkaroundEnabled) {
25 request.getParameter("foo"); // simply read any parameter (existing or not) to "prime" the request
26 }
27 }
我們可以看到該方法只是簡單的設置了encoding 和locale ，做的只是一些輔助的工作。
(2)prepare.createActionContext(request, response)
我們回到StrutsPrepareAndExecuteFilter的doFilter方法，看到第10行代碼：prepare.createActionContext(request, response);這是action上下文的創建，ActionContext是一個容器，這個容易主要存儲request、session、application、parameters等相關信 息.ActionContext是一個線程的本地變量，這意味着不同的action之間不會共享ActionContext，所以也不用考慮線程安全問 題。其實質是一個Map，key是標示request、session、……的字符串，值是其對應的對象，我們可以看到com.opensymphony.xwork2.ActionContext類中時如下定義的：
1 static ThreadLocal<ActionContext> actionContext = new ThreadLocal<ActionContext>();
我們看下PrepareOperations類的createActionContext方法：
1 /**
2 * Creates the action context and initializes the thread local
3 */
4 public ActionContext createActionContext(HttpServletRequest request, HttpServletResponse response) {
5 ActionContext ctx;
6 Integer counter = 1;
7 Integer oldCounter = (Integer) request.getAttribute(CLEANUP_RECURSION_COUNTER);
8 if (oldCounter != null) {
9 counter = oldCounter + 1;
10 }
11 //此處是從ThreadLocal中獲取此ActionContext變量
12 ActionContext oldContext = ActionContext.getContext();
13 if (oldContext != null) {
14 // detected existing context, so we are probably in a forward
15 ctx = new ActionContext(new HashMap<String, Object>(oldContext.getContextMap()));
16 } else {
17 ValueStack stack = dispatcher.getContainer().getInstance(ValueStackFactory.class).createValueStack();
18 stack.getContext().putAll(dispatcher.createContextMap(request, response, null, servletContext));
19 //stack.getContext()返回的是一個Map<String，Object>，根據此Map構造一個ActionContext
20 ctx = new ActionContext(stack.getContext());
21 }
22 request.setAttribute(CLEANUP_RECURSION_COUNTER, counter);
23 //將ActionContext存到ThreadLocal
24 ActionContext.setContext(ctx);
25 return ctx;
26 }
上面第18行代碼中dispatcher.createContextMap，如何封裝相關參數：
1 public Map<String,Object> createContextMap(HttpServletRequest request, HttpServletResponse response,
2 ActionMapping mapping, ServletContext context) {
3
4 // request map wrapping the http request objects
5 Map requestMap = new RequestMap(request);
6
7 // parameters map wrapping the http parameters. ActionMapping parameters are now handled and applied separately
8 Map params = new HashMap(request.getParameterMap());
9
10 // session map wrapping the http session
11 Map session = new SessionMap(request);
12
13 // application map wrapping the ServletContext
14 Map application = new ApplicationMap(context);
15 //requestMap、params、session等Map封裝成為一個上下文Map
16 Map<String,Object> extraContext = createContextMap(requestMap, params, session, application, request, response, context);
17
18 if (mapping != null) {
19 extraContext.put(ServletActionContext.ACTION_MAPPING, mapping);
20 }
21 return extraContext;
22 }
(3)request = prepare.wrapRequest(request)
我們再次回到StrutsPrepareAndExecuteFilter的doFilter方法中，看到第15行：request = prepare.wrapRequest(request);這一句是對request進行包裝的，我們看下prepare的wrapRequest方法：
1 public HttpServletRequest wrapRequest(HttpServletRequest oldRequest) throws ServletException {
2 HttpServletRequest request = oldRequest;
3 try {
4 // Wrap request first, just in case it is multipart/form-data
5 // parameters might not be accessible through before encoding (ww-1278)
6 request = dispatcher.wrapRequest(request, servletContext);
7 } catch (IOException e) {
8 throw new ServletException("Could not wrap servlet request with MultipartRequestWrapper!", e);
9 }
10 return request;
11 }
由第6行我們可以看到它里面調用的是dispatcher的wrapRequest方法，並且將servletContext對象也傳進去了，我們看下dispatcher的wrapRequest：
1 public HttpServletRequest wrapRequest(HttpServletRequest request, ServletContext servletContext) throws IOException {
2 // don't wrap more than once
3 if (request instanceof StrutsRequestWrapper) {
4 return request;
5 }
6
7 String content_type = request.getContentType();
8 //如果content_type是multipart/form-data類型，則將request包裝成MultiPartRequestWrapper對象，否則包裝成StrutsRequestWrapper對象
9 if (content_type != null && content_type.contains("multipart/form-data")) {
10 MultiPartRequest mpr = getMultiPartRequest();
11 LocaleProvider provider = getContainer().getInstance(LocaleProvider.class);
12 request = new MultiPartRequestWrapper(mpr, request, getSaveDir(servletContext), provider);
13 } else {
14 request = new StrutsRequestWrapper(request, disableRequestAttributeValueStackLookup);
15 }
16
17 return request;
18 }
此次包裝根據請求內容的類型不同，返回不同的對象，如果為multipart/form-data類型，則返回MultiPartRequestWrapper類型的對象，該對象服務於文件上傳，否則返回StrutsRequestWrapper類型的對象，MultiPartRequestWrapper是StrutsRequestWrapper的子類，而這兩個類都是HttpServletRequest接口的實現。
(4)ActionMapping mapping = prepare.findActionMapping(request, response, true)
包裝request后，通過ActionMapper的getMapping()方法得到請求的Action，Action的配置信息存儲在ActionMapping對象中，如StrutsPrepareAndExecuteFilter的doFilter方法中第16行：ActionMapping mapping = prepare.findActionMapping(request, response, true);我們找到prepare對象的findActionMapping方法：
1 public ActionMapping findActionMapping(HttpServletRequest request, HttpServletResponse response, boolean forceLookup) {
2 //首先從request對象中取mapping對象，看是否存在
3 ActionMapping mapping = (ActionMapping) request.getAttribute(STRUTS_ACTION_MAPPING_KEY);
4 //不存在就創建一個
5 if (mapping == null || forceLookup) {
6 try {
7 //首先創建ActionMapper對象，通過ActionMapper對象創建mapping對象
8 mapping = dispatcher.getContainer().getInstance(ActionMapper.class).getMapping(request, dispatcher.getConfigurationManager());
9 if (mapping != null) {
10 request.setAttribute(STRUTS_ACTION_MAPPING_KEY, mapping);
11 }
12 } catch (Exception ex) {
13 dispatcher.sendError(request, response, servletContext, HttpServletResponse.SC_INTERNAL_SERVER_ERROR, ex);
14 }
15 }
16
17 return mapping;
18 }
下面是ActionMapper接口的實現類DefaultActionMapper的getMapping()方法的源代碼：
1 public ActionMapping getMapping(HttpServletRequest request, ConfigurationManager configManager) {
2 ActionMapping mapping = new ActionMapping();
3 //獲得請求的uri，即請求路徑URL中工程名以后的部分，如/userAction.action
4 String uri = getUri(request);
5 //修正url的帶;jsessionid 時找不到的bug
6 int indexOfSemicolon = uri.indexOf(";");
7 uri = (indexOfSemicolon > -1) ? uri.substring(0, indexOfSemicolon) : uri;
8 //刪除擴展名，如.action或者.do
9 uri = dropExtension(uri, mapping);
10 if (uri == null) {
11 return null;
12 }
13 //從uri中分離得到請求的action名、命名空間。
14 parseNameAndNamespace(uri, mapping, configManager);
15 //處理特殊的請求參數
16 handleSpecialParameters(request, mapping);
17 //如果允許動態方法調用，即形如/userAction!getAll.action的請求，分離action名和方法名
18 return parseActionName(mapping);
19 }
下面對getMapping方法中的重要部分一一講解：
①：parseNameAndNamespace(uri, mapping, configManager)
我們主要看下第14行的parseNameAndNamespace(uri, mapping, configManager);這個方法的主要作用是分離出action名和命名空間：
1 protected void parseNameAndNamespace(String uri, ActionMapping mapping, ConfigurationManager configManager) {
2 String namespace, name;
3 int lastSlash = uri.lastIndexOf("/"); //最后的斜桿的位置
4 if (lastSlash == -1) {
5 namespace = "";
6 name = uri;
7 } else if (lastSlash == 0) {
8 // ww-1046, assume it is the root namespace, it will fallback to
9 // default
10 // namespace anyway if not found in root namespace.
11 namespace = "/";
12 name = uri.substring(lastSlash + 1);
13 //允許采用完整的命名空間,即設置命名空間是否必須進行精確匹配
14 } else if (alwaysSelectFullNamespace) {
15 // Simply select the namespace as everything before the last slash
16 namespace = uri.substring(0, lastSlash);
17 name = uri.substring(lastSlash + 1);
18 } else {
19 // Try to find the namespace in those defined, defaulting to ""
20 Configuration config = configManager.getConfiguration();
21 String prefix = uri.substring(0, lastSlash); //臨時的命名空間，將會用來進行匹配
22 namespace = "";//將命名空間暫時設為""
23 boolean rootAvailable = false;//rootAvailable作用是判斷配置文件中是否配置了命名空間"/"
24 // Find the longest matching namespace, defaulting to the default
25 for (Object cfg : config.getPackageConfigs().values()) { //循環遍歷配置文件中的package標簽
26 String ns = ((PackageConfig) cfg).getNamespace(); //獲取每個package標簽的namespace屬性
27 //進行匹配
28 if (ns != null && prefix.startsWith(ns) && (prefix.length() == ns.length() || prefix.charAt(ns.length()) == '/')) {
29 if (ns.length() > namespace.length()) {
30 namespace = ns;
31 }
32 }
33 if ("/".equals(ns)) {
34 rootAvailable = true;
35 }
36 }
37
38 name = uri.substring(namespace.length() + 1);
39
40 // Still none found, use root namespace if found
41 if (rootAvailable && "".equals(namespace)) {
42 namespace = "/";
43 }
44 }
45
46 if (!allowSlashesInActionNames) {
47 int pos = name.lastIndexOf('/');
48 if (pos > -1 && pos < name.length() - 1) {
49 name = name.substring(pos + 1);
50 }
51 }
52 //將分離后的acion名和命名空間保存到mapping對象
53 mapping.setNamespace(namespace);
54 mapping.setName(cleanupActionName(name));
55 }
看到上面代碼的第14行，參數alwaysSelectFullNamespace我們可以通過名字就能大概猜出來"允許采用完整的命名空間"，即設置命名空間是否必須進行精確匹配，true必須，false可以模糊匹配，默認是false。進行精確匹配時要求請求url中的命名空間必須與配置文件中配置的某個命名空間必須相同，如果沒有找到相同的則匹配失敗。這個參數可通過struts2的"struts.mapper.alwaysSelectFullNamespace"常量配置，如：<constant name="struts.mapper.alwaysSelectFullNamespace" value="true" />。當alwaysSelectFullNamespace為true時，將uri以lastSlash為分割，左邊的為namespace，右邊的為name。如：http://localhost:8080/myproject/home/actionName!method.action,此時uri為/home/actionName!method.action(不過前面把后綴名去掉了，變成/home/actionName!method)，lastSlash的,當前值是5，這樣namespace為"/home", name為actionName!method。
我們再看到上面代碼第18行到第44行：當上面的所有條件都不滿足時，其中包括alwaysSelectFullNamespace 為false(命名空間進行模糊匹配)，將由此部分處理，進行模糊匹配。第1句，通過configManager.getConfiguration()從配置管理器中獲得配置對象Configuration，Configuration中存放着struts2的所有配置，形式是將xml文檔的相應元素封裝為java bean，如<package>元素被封裝到PackageConfig類中，這個一會兒會用到。第2句按lastSlash將uri截取出prefix，這是一個臨時的命名空間，之后將會拿prefix進行模糊匹配。第3句namespace = ""，將命名空間暫時設為""。第4句創建並設置rootAvailable，rootAvailable作用是判斷配置文件中是否配置了命名空間"/"，true為配置了，false未配置，下面for語句將會遍歷我們配置的所有包(<package>)，同時設置rootAvailable。第5句for，通過config.getPackageConfigs()獲得所有已經配置的包，然后遍歷。String ns = ((PackageConfig) cfg).getNamespace()獲得當前包的命名空間ns，之后的if句是進行模糊匹配的核心，我摘出來單獨說，如下：
1 if (ns != null && prefix.startsWith(ns) && (prefix.length() == ns.length() || prefix.charAt(ns.length()) == '/')) {
2 if (ns.length() > namespace.length()) {
3 namespace = ns;
4 }
5 }
ns != null && prefix.startsWith(ns)這部分判斷當ns不等於空並且ns是prefix的前綴。prefix.length() == ns.length()當二者長度相等時，結合前面部分就是ns是prefix的前綴並且二者長度相等，最終結論就是ns和prefix相等。如果前面的條件不成立，則說明prefix的長度大於ns。prefix.charAt(ns.length()) == '/')意思是prefix中與ns不相等的字符中的第一個字符必須是"/"，也就是說，在命名空間采用斜杠分級的形式中，ns必須是prefix的某一子集，如：/common/home 是用戶配置的命名空間，則在http的請求url中，/common/home/index1、/common/home/index2、/common/home/index/aaa 都是正確的，都可以成功的匹配到/common/home，而/common/homeaa、/common/homea/aaa都是錯誤的。接着if (ns.length() > namespace.length()) 句，目的是找出字符長度最長的。因為命名空間采用的是分級的，則長度越長所表示的越精確，如/common/home/index比/common/home精確。之后將namespace = ns。
我們接着往下看if ("/".equals(ns)) 當我們配置了"/"這個命名空間時，將rootAvailable = true。name = uri.substring(namespace.length() + 1)句不涉及到命名空間就不說了。if (rootAvailable && "".equals(namespace))如果通過上面的for循環沒有找到匹配的命名空間即namespace的值仍然是當初設置的""，但卻配置了"/"時，將命名空間設為"/"。
我們再看到第46到51行那個if語句：
1 if (!allowSlashesInActionNames) {
2 int pos = name.lastIndexOf('/');
3 if (pos > -1 && pos < name.length() - 1) {
4 name = name.substring(pos + 1);
5 }
6 }
allowSlashesInActionNames代表是否允許"/"出現在Action的名稱中，默認為false，如果不允許"/"出現在Action名中，並且這時的Action名中有"/"，則取"/"后面的部分。
下面是命名空間匹配規則的總結：
(1). 如果請求url中沒有命名空間時，將采用"/"作為命名空間。
(2). 當我們將常量 struts.mapper.alwaysSelectFullNamespace設為true時，那么請求url的命名空間必須和配置文件配置的完全相同才能匹配。
當將常量 struts.mapper.alwaysSelectFullNamespace設為false時，那么請求url的命名空間和配置文件配置的可按模糊匹配。規則：
a.如果配置文件中配置了/common 而url中的命名空間/common、/common/home、/common/home/index等等都是可匹配的，即子命名空間可匹配父命名空間。
b.如果對於某個url請求中的命名空間同時匹配了倆個或倆個以上的配置文件中配置的命名空間，則選字符最長的，如：當前請求的命名空間為/common/home/index/aaaa, 而我們在配置時同時配置 了/common/home、/common/home/index 則將會匹配命名空間最長的，即/common/home/index。
(3).最后，如果請求的命名空間在配置中沒有匹配到時，將采用""作為命名空間。如果沒有設置為""的命名空間將拋出404錯誤。
②：parseActionName(mapping)
好了，到這里parseNameAndNamespace方法已經分析完了，我們再次回到getMapping方法中去，看到16行：handleSpecialParameters(request, mapping);好像是處理特殊參數的函數吧，里面有點看不懂，暫時就不管，以后有時間再研究。我們看到18行：return parseActionName(mapping);主要是用來處理形如/userAction!getAll.action的請求，分離action名和方法名：
1 protected ActionMapping parseActionName(ActionMapping mapping) {
2 if (mapping.getName() == null) {
3 return null;
4 }
5 //如果允許動態方法調用
6 if (allowDynamicMethodCalls) {
7 // handle "name!method" convention.
8 String name = mapping.getName();
9 int exclamation = name.lastIndexOf("!");
10 //如果包含"!"就進行分離
11 if (exclamation != -1) {
12 //分離出action名
13 mapping.setName(name.substring(0, exclamation));
14 //分離出方法名
15 mapping.setMethod(name.substring(exclamation + 1));
16 }
17 }
18 return mapping;
19 }
到此為止getMapping方法已經分析結束了！
(5)execute.executeAction(request, response, mapping)
上面我們分析完了mapping的獲取，繼續看doFilter方法：
1 //如果mapping為空，則認為不是調用action,會調用下一個過濾器鏈，直到獲取到mapping才調用action
2 if (mapping == null) {
3 boolean handled = execute.executeStaticResourceRequest(request, response);
4 if (!handled) {
5 chain.doFilter(request, response);
6 }
7 } else {
8 //執行action
9 execute.executeAction(request, response, mapping);
10 }
如果mapping對象不為空，則會執行action，我們看到上面代碼第9行：execute是ExecuteOperations類的對象，ExecuteOperations類在包org.apache.struts2.dispatcher.ng下面，我們找到它里面的executeAction方法：
1 public void executeAction(HttpServletRequest request, HttpServletResponse response, ActionMapping mapping) throws ServletException {
2 dispatcher.serviceAction(request, response, servletContext, mapping);
3 }
我們可以看到它里面只是簡單的調用了dispatcher的serviceAction方法：我們找到dispatcher的serviceAction方法：
1 public void serviceAction(HttpServletRequest request, HttpServletResponse response, ServletContext context,
2 ActionMapping mapping) throws ServletException {
3 //封轉上下文環境，主要將requestMap、params、session等Map封裝成為一個上下文Map
4 Map<String, Object> extraContext = createContextMap(request, response, mapping, context);
5
6 // If there was a previous value stack, then create a new copy and pass it in to be used by the new Action
7 ValueStack stack = (ValueStack) request.getAttribute(ServletActionContext.STRUTS_VALUESTACK_KEY);
8 boolean nullStack = stack == null;
9 if (nullStack) {
10 ActionContext ctx = ActionContext.getContext();
11 if (ctx != null) {
12 stack = ctx.getValueStack();
13 }
14 }
15 if (stack != null) {
16 extraContext.put(ActionContext.VALUE_STACK, valueStackFactory.createValueStack(stack));
17 }
18
19 String timerKey = "Handling request from Dispatcher";
20 try {
21 UtilTimerStack.push(timerKey);
22 String namespace = mapping.getNamespace();//從mapping對象獲取命名空間
23 String name = mapping.getName(); //獲取請求的action名
24 String method = mapping.getMethod(); //獲取請求方法
25 //得到配置對象
26 Configuration config = configurationManager.getConfiguration();
27 //根據執行上下文參數，命名空間，名稱等創建用戶自定義Action的代理對象
28 ActionProxy proxy = config.getContainer().getInstance(ActionProxyFactory.class).createActionProxy(
29 namespace, name, method, extraContext, true, false);
30
31 request.setAttribute(ServletActionContext.STRUTS_VALUESTACK_KEY, proxy.getInvocation().getStack());
32
33 // if the ActionMapping says to go straight to a result, do it!
34 //如果配置文件中執行的這個action配置了result，就直接轉到result
35 if (mapping.getResult() != null) {
36 Result result = mapping.getResult();
37 result.execute(proxy.getInvocation());
38 } else {
39 proxy.execute();
40 }
41
42 // If there was a previous value stack then set it back onto the request
43 if (!nullStack) {
44 request.setAttribute(ServletActionContext.STRUTS_VALUESTACK_KEY, stack);
45 }
46 } catch (ConfigurationException e) {
47 // WW-2874 Only log error if in devMode
48 if (devMode) {
49 String reqStr = request.getRequestURI();
50 if (request.getQueryString() != null) {
51 reqStr = reqStr + "?" + request.getQueryString();
52 }
53 LOG.error("Could not find action or result\n" + reqStr, e);
54 } else {
55 if (LOG.isWarnEnabled()) {
56 LOG.warn("Could not find action or result", e);
57 }
58 }
59 sendError(request, response, context, HttpServletResponse.SC_NOT_FOUND, e);
60 } catch (Exception e) {
61 if (handleException || devMode) {
62 sendError(request, response, context, HttpServletResponse.SC_INTERNAL_SERVER_ERROR, e);
63 } else {
64 throw new ServletException(e);
65 }
66 } finally {
67 UtilTimerStack.pop(timerKey);
68 }
69 }
最后通過Result完成頁面跳轉！
下面我們來看看ActionInvocation是如何工作的：
ActionInvocation是Xworks 中Action 調度的核心。而對Interceptor 的調度，也正是由ActionInvocation負責。ActionInvocation 是一個接口，而DefaultActionInvocation 則是Webwork 對ActionInvocation的默認實現。
Interceptor的調度流程大致如下：
1.ActionInvocation初始化時，根據配置，加載Action相關的所有Interceptor。
2. 通過ActionInvocation.invoke方法調用Action實現時，執行Interceptor。
Interceptor將很多功能從我們的Action中獨立出來，大量減少了我們Action的代碼，獨立出來的行為具有很好的重用性。XWork、WebWork的許多功能都是有Interceptor實現，可以在配置文件中組裝Action用到的Interceptor，它會按照你指定的順序，在Action執行前后運行。
Struts2和struts1的比較
struts2相對於struts1來說簡單了很多，並且功能強大了很多，我們可以從幾個方面來看：
從體系結構來看：struts2大量使用攔截器來出來請求，從而允許與業務邏輯控制器 與 servlet-api分離，避免了侵入性；而struts1.x在action中明顯的侵入了servlet-api.
從線程安全分析：struts2.x是線程安全的，每一個對象產生一個實例，避免了線程安全問題；而struts1.x在action中屬於單線程。
性能方面：struts2.x測試可以脫離web容器，而struts1.x依賴servlet-api，測試需要依賴web容器。
請求參數封裝對比：struts2.x使用ModelDriven模式，這樣我們 直接 封裝model對象，無需要繼承任何struts2的基類，避免了侵入性。
標簽的優勢：標簽庫幾乎可以完全替代JSTL的標簽庫，並且 struts2.x支持強大的ognl表達式。
當然，struts2和struts1相比，在 文件上傳，數據校驗 等方面也 方便了好多。在這就不詳談了。
總結：以前總是只會用struts2框架，對里面的原理沒有一個很清晰的認識，這兩天花時間把struts2框架的源碼分析了一下，對它的工作原理有個更深的認識。既然是開源框架，有時間久得去研究研究它的源碼，不然開源就失去了意義了，不要只停留在會用的層面上！