請求過程
struts2 架構圖如下圖所示：
依照上圖，我們可以看出一個請求在struts的處理大概有如下步驟：
1、客戶端初始化一個指向Servlet容器（例如Tomcat）的請求；
2、這個請求經過一系列的過濾器（Filter）（這些過濾器中有一個叫做ActionContextCleanUp的可選過濾器，這個過濾器對於Struts2和其他框架的集成很有幫助，例如：SiteMesh Plugin）；
3、接着StrutsPrepareAndExecuteFilter被調用，StrutsPrepareAndExecuteFilter詢問ActionMapper來決定這個請求是否需要調用某個Action；
4、如果ActionMapper決定需要調用某個Action，FilterDispatcher把請求的處理交給ActionProxy；
5、ActionProxy通過Configuration Manager詢問框架的配置文件，找到需要調用的Action類；
6、ActionProxy創建一個ActionInvocation的實例。
7、ActionInvocation實例使用命名模式來調用，在調用Action的過程前后，涉及到相關攔截器（Intercepter）的調用。
8、一旦Action執行完畢，ActionInvocation負責根據struts.xml中的配置找到對應的返回結果。返回結果通常是（但不總是，也可能是另外的一個Action鏈）一個需要被表示的JSP或者FreeMarker的模版。在表示的過程中可以使用Struts2 框架中繼承的標簽。在這個過程中需要涉及到ActionMapper。
9、接着按照相反次序執行攔截器鏈 ( 執行 Action 調用之后的部分 )。最后，響應通過濾器鏈返回（過濾器技術執行流程與攔截器一樣，都是先執行前面部分，后執行后面部）。如果過濾器鏈中存在 ActionContextCleanUp，FilterDispatcher 不會清理線程局部的 ActionContext。如果不存在 ActionContextCleanUp 過濾器，FilterDispatcher 會清除所有線程局部變量。
strut2源碼分析
首先我們使用struts2框架都會在web.xml中注冊和映射struts2，配置內容如下：
<filter>
<filter-name>struts2</filter-name>
<filter-class>org.apache.struts2.dispatcher.ng.filter.StrutsPrepareAndExecuteFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>struts2</filter-name>
<url-pattern>/*</url-pattern>
</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，並執行初始化方法，初始化方法如下：
public void init(FilterConfig filterConfig) throws ServletException { InitOperations init = new InitOperations(); Dispatcher dispatcher = null; try { //封裝filterConfig，其中有個主要方法getInitParameterNames將配置文件中的初始化參數名字以String格式存儲在List中 FilterHostConfig config = new FilterHostConfig(filterConfig); //初始化struts內部日志 init.initLogging(config); //創建dispatcher ，並初始化 dispatcher = init.initDispatcher(config); init.initStaticContentLoader(config, dispatcher); //初始化類屬性：prepare 、execute prepare = new PrepareOperations(filterConfig.getServletContext(), dispatcher); execute = new ExecuteOperations(filterConfig.getServletContext(), dispatcher); this.excludedPatterns = init.buildExcludedPatternsList(dispatcher); //回調空的postInit方法 postInit(dispatcher, filterConfig); } finally { if (dispatcher != null) { dispatcher.cleanUpAfterInit(); } init.cleanup(); } }
關於封裝filterConfig，首先看下FilterHostConfig ，源碼如下：
public class FilterHostConfig implements HostConfig { private FilterConfig config; //構造方法 public FilterHostConfig(FilterConfig config) { this.config = config; } //根據init-param配置的param-name獲取param-value的值 public String getInitParameter(String key) { return config.getInitParameter(key); } //返回初始化參數名的迭代器 public Iterator<String> getInitParameterNames() { return MakeIterator.convert(config.getInitParameterNames()); } //返回Servlet上下文 public ServletContext getServletContext() { return config.getServletContext(); } }
接下來，看下StrutsPrepareAndExecuteFilter中init方法中dispatcher = init.initDispatcher(config);這是初始化dispatcher的。
public Dispatcher initDispatcher( HostConfig filterConfig ) { Dispatcher dispatcher = createDispatcher(filterConfig); dispatcher.init(); return dispatcher; }
創建Dispatcher，會讀取 filterConfig 中的配置信息，將配置信息解析出來，封裝成為一個Map，然后根絕servlet上下文和參數Map構造Dispatcher ：
private Dispatcher createDispatcher( HostConfig filterConfig ) { //存放參數的Map Map<String, String> params = new HashMap<String, String>(); //將參數存放到Map for ( Iterator e = filterConfig.getInitParameterNames(); e.hasNext(); ) { String name = (String) e.next(); String value = filterConfig.getInitParameter(name); params.put(name, value); } //根據servlet上下文和參數Map構造Dispatcher return new Dispatcher(filterConfig.getServletContext(), params); }
這樣dispatcher對象創建完成，接着就是dispatcher對象的初始化，打開Dispatcher類，看到它的init方法如下：
public void init() { if (configurationManager == null) { configurationManager = createConfigurationManager(BeanSelectionProvider.DEFAULT_BEAN_NAME); } try { init_FileManager(); //加載org/apache/struts2/default.properties init_DefaultProperties(); //加載struts-default.xml,struts-plugin.xml,struts.xml init_TraditionalXmlConfigurations(); init_LegacyStrutsProperties(); //用戶自己實現的ConfigurationProviders類 init_CustomConfigurationProviders(); //Filter的初始化參數 init_FilterInitParameters() ; init_AliasStandardObjects() ; Container container = init_PreloadConfiguration(); container.inject(this); init_CheckWebLogicWorkaround(container); if (!dispatcherListeners.isEmpty()) { for (DispatcherListener l : dispatcherListeners) { l.dispatcherInitialized(this); } } } catch (Exception ex) { if (LOG.isErrorEnabled()) LOG.error("Dispatcher initialization failed", ex); throw new StrutsException(ex); } }
這里主要是加載一些配置文件的，將按照順序逐一加載：default.properties，struts-default.xml,struts-plugin.xml,struts.xml，……
現在，我們回到StrutsPrepareAndExecuteFilter類中，剛才我們分析了StrutsPrepareAndExecuteFilter類的init方法，該方法在web容器一啟動就會調用的，當用戶訪問某個action的時候，首先調用核心過濾器StrutsPrepareAndExecuteFilter的doFilter方法，該方法內容如下：
public void doFilter(ServletRequest req, ServletResponse res, FilterChain chain) throws IOException, ServletException { HttpServletRequest request = (HttpServletRequest) req; HttpServletResponse response = (HttpServletResponse) res; try { //設置編碼和國際化 prepare.setEncodingAndLocale(request, response); //創建action上下文 prepare.createActionContext(request, response); prepare.assignDispatcherToThread(); if (excludedPatterns != null && prepare.isUrlExcluded(request, excludedPatterns)) { chain.doFilter(request, response); } else { request = prepare.wrapRequest(request); ActionMapping mapping = prepare.findActionMapping(request, response, true); //如果mapping為空，則認為不是調用action,會調用下一個過濾器鏈，直到獲取到mapping才調用action if (mapping == null) { boolean handled = execute.executeStaticResourceRequest(request, response); if (!handled) { chain.doFilter(request, response); } } else { //執行action execute.executeAction(request, response, mapping); } } } finally { prepare.cleanupRequest(request); } }
下面對doFilter方法中的重點部分一一講解：
(1)prepare.setEncodingAndLocale(request, response)
public void setEncodingAndLocale(HttpServletRequest request, HttpServletResponse response) { dispatcher.prepare(request, response); }
這方法里面我們可以看到它只是調用了dispatcher的prepare方法而已，下面我們看看dispatcher的prepare方法：
String encoding = null; if (defaultEncoding != null) { encoding = defaultEncoding; } // check for Ajax request to use UTF-8 encoding strictly http://www.w3.org/TR/XMLHttpRequest/#the-send-method if ("XMLHttpRequest".equals(request.getHeader("X-Requested-With"))) { encoding = "UTF-8"; } Locale locale = null; if (defaultLocale != null) { locale = LocalizedTextUtil.localeFromString(defaultLocale, request.getLocale()); } if (encoding != null) { applyEncoding(request, encoding); } if (locale != null) { response.setLocale(locale); } if (paramsWorkaroundEnabled) { request.getParameter("foo"); // simply read any parameter (existing or not) to "prime" the request } }
我們可以看到該方法只是簡單的設置了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類中時如下定義的：
static ThreadLocal<ActionContext> actionContext = new ThreadLocal<ActionContext>();
我們看下PrepareOperations類的createActionContext方法：
public void prepare(HttpServletRequest request, HttpServletResponse response) { /** * Creates the action context and initializes the thread local */ public ActionContext createActionContext(HttpServletRequest request, HttpServletResponse response) { ActionContext ctx; Integer counter = 1; Integer oldCounter = (Integer) request.getAttribute(CLEANUP_RECURSION_COUNTER); if (oldCounter != null) { counter = oldCounter + 1; } //此處是從ThreadLocal中獲取此ActionContext變量 ActionContext oldContext = ActionContext.getContext(); if (oldContext != null) { // detected existing context, so we are probably in a forward ctx = new ActionContext(new HashMap<String, Object>(oldContext.getContextMap())); } else { ValueStack stack = dispatcher.getContainer().getInstance(ValueStackFactory.class).createValueStack(); stack.getContext().putAll(dispatcher.createContextMap(request, response, null, servletContext)); //stack.getContext()返回的是一個Map<String，Object>，根據此Map構造一個ActionContext ctx = new ActionContext(stack.getContext()); } request.setAttribute(CLEANUP_RECURSION_COUNTER, counter); //將ActionContext存到ThreadLocal ActionContext.setContext(ctx); return ctx; }
上面第18行代碼中dispatcher.createContextMap，如何封裝相關參數：
public Map<String,Object> createContextMap(HttpServletRequest request, HttpServletResponse response, ActionMapping mapping, ServletContext context) { // request map wrapping the http request objects Map requestMap = new RequestMap(request); // parameters map wrapping the http parameters. ActionMapping parameters are now handled and applied separately Map params = new HashMap(request.getParameterMap()); // session map wrapping the http session Map session = new SessionMap(request); // application map wrapping the ServletContext Map application = new ApplicationMap(context); //requestMap、params、session等Map封裝成為一個上下文Map Map<String,Object> extraContext = createContextMap(requestMap, params, session, application, request, response, context); if (mapping != null) { extraContext.put(ServletActionContext.ACTION_MAPPING, mapping); } return extraContext; }
(3)request = prepare.wrapRequest(request)
我們再次回到StrutsPrepareAndExecuteFilter的doFilter方法中，看到第15行：request = prepare.wrapRequest(request);這一句是對request進行包裝的，我們看下prepare的wrapRequest方法：
public HttpServletRequest wrapRequest(HttpServletRequest oldRequest) throws ServletException { HttpServletRequest request = oldRequest; try { // Wrap request first, just in case it is multipart/form-data // parameters might not be accessible through before encoding (ww-1278) request = dispatcher.wrapRequest(request, servletContext); } catch (IOException e) { throw new ServletException("Could not wrap servlet request with MultipartRequestWrapper!", e); } return request; }
我們看下dispatcher的wrapRequest：
public HttpServletRequest wrapRequest(HttpServletRequest request, ServletContext servletContext) throws IOException { // don't wrap more than once if (request instanceof StrutsRequestWrapper) { return request; } String content_type = request.getContentType(); //如果content_type是multipart/form-data類型，則將request包裝成MultiPartRequestWrapper對象，否則包裝成StrutsRequestWrapper對象 if (content_type != null && content_type.contains("multipart/form-data")) { MultiPartRequest mpr = getMultiPartRequest(); LocaleProvider provider = getContainer().getInstance(LocaleProvider.class); request = new MultiPartRequestWrapper(mpr, request, getSaveDir(servletContext), provider); } else { request = new StrutsRequestWrapper(request, disableRequestAttributeValueStackLookup); } return request; }
此次包裝根據請求內容的類型不同，返回不同的對象，如果為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方法：
public ActionMapping findActionMapping(HttpServletRequest request, HttpServletResponse response, boolean forceLookup) { //首先從request對象中取mapping對象，看是否存在 ActionMapping mapping = (ActionMapping) request.getAttribute(STRUTS_ACTION_MAPPING_KEY); //不存在就創建一個 if (mapping == null || forceLookup) { try { //首先創建ActionMapper對象，通過ActionMapper對象創建mapping對象 mapping = dispatcher.getContainer().getInstance(ActionMapper.class).getMapping(request, dispatcher.getConfigurationManager()); if (mapping != null) { request.setAttribute(STRUTS_ACTION_MAPPING_KEY, mapping); } } catch (Exception ex) { dispatcher.sendError(request, response, servletContext, HttpServletResponse.SC_INTERNAL_SERVER_ERROR, ex); } } return mapping; }
下面是ActionMapper接口的實現類DefaultActionMapper的getMapping()方法的源代碼：
public ActionMapping getMapping(HttpServletRequest request, ConfigurationManager configManager) { ActionMapping mapping = new ActionMapping(); //獲得請求的uri，即請求路徑URL中工程名以后的部分，如/userAction.action String uri = getUri(request); //修正url的帶;jsessionid 時找不到的bug int indexOfSemicolon = uri.indexOf(";"); uri = (indexOfSemicolon > -1) ? uri.substring(0, indexOfSemicolon) : uri; //刪除擴展名，如.action或者.do uri = dropExtension(uri, mapping); if (uri == null) { return null; } //從uri中分離得到請求的action名、命名空間。 parseNameAndNamespace(uri, mapping, configManager); //處理特殊的請求參數 handleSpecialParameters(request, mapping); //如果允許動態方法調用，即形如/userAction!getAll.action的請求，分離action名和方法名 return parseActionName(mapping); }
下面對getMapping方法中的重要部分一一講解：
①：parseNameAndNamespace(uri, mapping, configManager)
我們主要看下第14行的parseNameAndNamespace(uri, mapping, configManager);這個方法的主要作用是分離出action名和命名空間：
protected void parseNameAndNamespace(String uri, ActionMapping mapping, ConfigurationManager configManager) { String namespace, name; int lastSlash = uri.lastIndexOf("/"); //最后的斜桿的位置 if (lastSlash == -1) { namespace = ""; name = uri; } else if (lastSlash == 0) { // ww-1046, assume it is the root namespace, it will fallback to // default // namespace anyway if not found in root namespace. namespace = "/"; name = uri.substring(lastSlash + 1); //允許采用完整的命名空間,即設置命名空間是否必須進行精確匹配 } else if (alwaysSelectFullNamespace) { // Simply select the namespace as everything before the last slash namespace = uri.substring(0, lastSlash); name = uri.substring(lastSlash + 1); } else { // Try to find the namespace in those defined, defaulting to "" Configuration config = configManager.getConfiguration(); String prefix = uri.substring(0, lastSlash); //臨時的命名空間，將會用來進行匹配 namespace = "";//將命名空間暫時設為"" boolean rootAvailable = false;//rootAvailable作用是判斷配置文件中是否配置了命名空間"/" // Find the longest matching namespace, defaulting to the default for (Object cfg : config.getPackageConfigs().values()) { //循環遍歷配置文件中的package標簽 String ns = ((PackageConfig) cfg).getNamespace(); //獲取每個package標簽的namespace屬性 //進行匹配 if (ns != null && prefix.startsWith(ns) && (prefix.length() == ns.length() || prefix.charAt(ns.length()) == '/')) { if (ns.length() > namespace.length()) { namespace = ns; } } if ("/".equals(ns)) { rootAvailable = true; } } name = uri.substring(namespace.length() + 1); // Still none found, use root namespace if found if (rootAvailable && "".equals(namespace)) { namespace = "/"; } } if (!allowSlashesInActionNames) { int pos = name.lastIndexOf('/'); if (pos > -1 && pos < name.length() - 1) { name = name.substring(pos + 1); } } //將分離后的acion名和命名空間保存到mapping對象 mapping.setNamespace(namespace); mapping.setName(cleanupActionName(name)); }
看到上面代碼的第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。
②：parseActionName(mapping)
我們看到18行：return parseActionName(mapping);主要是用來處理形如/userAction!getAll.action的請求，分離action名和方法名：
protected ActionMapping parseActionName(ActionMapping mapping) { if (mapping.getName() == null) { return null; } //如果允許動態方法調用 if (allowDynamicMethodCalls) { // handle "name!method" convention. String name = mapping.getName(); int exclamation = name.lastIndexOf("!"); //如果包含"!"就進行分離 if (exclamation != -1) { //分離出action名 mapping.setName(name.substring(0, exclamation)); //分離出方法名 mapping.setMethod(name.substring(exclamation + 1)); } } return mapping; }
到此為止getMapping方法已經分析結束了！
(5)execute.executeAction(request, response, mapping)
上面我們分析完了mapping的獲取，繼續看doFilter方法：
//如果mapping為空，則認為不是調用action,會調用下一個過濾器鏈 if (mapping == null) { //執行請求css,js文件。並返回是否成功。 boolean handled = execute.executeStaticResourceRequest(request, response); if (!handled) { chain.doFilter(request, response); } } else { //執行action execute.executeAction(request, response, mapping); }
如果mapping對象不為空，則會執行action
public void executeAction(HttpServletRequest request, HttpServletResponse response, ActionMapping mapping) throws ServletException { dispatcher.serviceAction(request, response, servletContext, mapping); }
我們可以看到它里面只是簡單的調用了dispatcher的serviceAction方法：我們找到dispatcher的serviceAction方法：
public void serviceAction(HttpServletRequest request, HttpServletResponse response, ActionMapping mapping) throws ServletException { //封轉上下文環境，主要將requestMap、params、session等Map封裝成為一個上下文Map Map<String, Object> extraContext = createContextMap(request, response, mapping); //如果之前沒有值棧，就從ActionContext中先取出值棧，放入extraContext ValueStack stack = (ValueStack) request.getAttribute(ServletActionContext.STRUTS_VALUESTACK_KEY); boolean nullStack = stack == null; if (nullStack) { ActionContext ctx = ActionContext.getContext(); if (ctx != null) { stack = ctx.getValueStack(); } } if (stack != null) { extraContext.put(ActionContext.VALUE_STACK, valueStackFactory.createValueStack(stack)); } String timerKey = "Handling request from Dispatcher"; try { UtilTimerStack.push(timerKey); String namespace = mapping.getNamespace();//獲得request請求里面的命名空間，即是struts.xml是的package節點元素 String name = mapping.getName();//獲得request請求里面的action名 String method = mapping.getMethod();//要執行action的方法 ActionProxy proxy = getContainer().getInstance(ActionProxyFactory.class).createActionProxy(namespace, name, method, extraContext, true, false);//獲得action的代理 request.setAttribute(ServletActionContext.STRUTS_VALUESTACK_KEY, proxy.getInvocation().getStack()); // 如果action映射是直接就跳轉到網頁的話， if (mapping.getResult() != null) { Result result = mapping.getResult(); result.execute(proxy.getInvocation()); } else { proxy.execute();//這里就是執行action } if (!nullStack) { request.setAttribute(ServletActionContext.STRUTS_VALUESTACK_KEY, stack); } } catch (ConfigurationException e) { logConfigurationException(request, e); sendError(request, response, HttpServletResponse.SC_NOT_FOUND, e); } catch (Exception e) { if (handleException || devMode) { sendError(request, response, HttpServletResponse.SC_INTERNAL_SERVER_ERROR, e); } else { throw new ServletException(e); } } finally { UtilTimerStack.pop(timerKey); } }
1.根據傳入的參數request, response, mapping來新建一個上下文Map。上下文Map就是一個存了關於RequestMap類,SessionMap類，ApplicationMap類等實例。即是request請求相關的信息，只是把他變成了對應的MAP類而以。
2.從request請求中找到對應的值棧(ValueStack)。如果沒有就新建值棧。然后存放到上下文Map里面，對應的KEY為ActionContext.VALUE_STACK常量的值。即是"com.opensymphony.xwork2.util.ValueStack.ValueStack"。
3.從Mapping參數中提取對應的request請求的命名空間，action名字和方法名。
4.從Container容器中找到ActionProxyFactory類，並根據request請求的命名空間，action名字和方法名，上下文Map來獲得對應的action代理類(ActionProxy)。然后更新request請求中的對應的值棧(ValueStack)。
5.根據Mapping參數來判斷是否為直接輸出結果。還是執行action代理類。
6.最后在判斷之前是否request請求沒有找到對應的值棧(ValueStack)。如果有找到值棧(ValueStack)，則更新request請求中的對應的值棧(ValueStack)。
所以我們的目標很明確就是要去看一下action代理類(ActionProxy)。了解他到底做了什么。才能明白如何找到對應的action類，並執行對應的方法。從上面我們也知道action代理類的新建是通過ActionProxyFactory接口實例來進行的。即是DefaultActionProxyFactory類的實例。顯然就是一個簡章的工廠模式。讓我們看一下新建action代理類的代碼吧。
DefaultActionProxyFactory類：
public ActionProxy createActionProxy(String namespace, String actionName, String methodName, Map<String, Object> extraContext, boolean executeResult, boolean cleanupContext) { ActionInvocation inv = createActionInvocation(extraContext, true); container.inject(inv); return createActionProxy(inv, namespace, actionName, methodName, executeResult, cleanupContext); }
Dispatcher類是重要的調結者，DefaultActionInvocation類是執行action類實例的行動者。而action代理類(ActionProxy類)則是他們之間的中間人。相當於Dispatcher類通過action代理類(ActionProxy類)命令DefaultActionInvocation類去執行action類實例。
DefaultActionProxyFactory類：
public ActionProxy createActionProxy(ActionInvocation inv, String namespace, String actionName, String methodName, boolean executeResult, boolean cleanupContext) { DefaultActionProxy proxy = new DefaultActionProxy(inv, namespace, actionName, methodName, executeResult, cleanupContext); container.inject(proxy); proxy.prepare(); return proxy; }
DefaultActionProxy類：
protected void prepare() { String profileKey = "create DefaultActionProxy: "; try { UtilTimerStack.push(profileKey); config = configuration.getRuntimeConfiguration().getActionConfig(namespace, actionName);//根據空間命名和action名來找到對應的配置信息 if (config == null && unknownHandlerManager.hasUnknownHandlers()) { config = unknownHandlerManager.handleUnknownAction(namespace, actionName); } if (config == null) { throw new ConfigurationException(getErrorMessage()); } resolveMethod();//找到對應的方法名。 if (config.isAllowedMethod(method)) { invocation.init(this); } else { throw new ConfigurationException(prepareNotAllowedErrorMessage()); } } finally { UtilTimerStack.pop(profileKey); } }
1.獲得ActionConfig類實例。並通過ActionConfig類實例找到對應的方法名。ActionConfig類就是存放配置文件里面的action元素節點的信息。
2.實初始化DefaultActionInvocation類的實例。即是根據ActionProxy類實例找到對應的action類實例(用戶自己定義的類)。
DefaultActionProxy類：
private void resolveMethod() { // 從配置中獲得方法名。如果還是空的話，就用默認的值。即是"execute"方法。 if (StringUtils.isEmpty(this.method)) { this.method = config.getMethodName(); if (StringUtils.isEmpty(this.method)) { this.method = ActionConfig.DEFAULT_METHOD; } methodSpecified = false; } }
DefaultActionInvocation類：
public void init(ActionProxy proxy) { this.proxy = proxy; Map<String, Object> contextMap = createContextMap(); // Setting this so that other classes, like object factories, can use the ActionProxy and other // contextual information to operate ActionContext actionContext = ActionContext.getContext(); if (actionContext != null) { actionContext.setActionInvocation(this); } createAction(contextMap);//找到對應的action類實例 if (pushAction) { stack.push(action); contextMap.put("action", action); } invocationContext = new ActionContext(contextMap); invocationContext.setName(proxy.getActionName()); createInterceptors(proxy); }
看了代碼就能清楚的知道一件事情。如果我們在struts.xml配置文件里面action元素節點里面沒有指定方法的時候，就用會默認的方法。即是execute方法。而關於init方法就能明確明白為了找到action類並實例他。init方法里面調用了倆個非重要的方法。一個是用於新建action類實例的方法createAction。一個是用於獲得相關攔截器的方法createInterceptors。看一下代碼吧。
DefaultActionInvocation類：
protected void createAction(Map<String, Object> contextMap) { // load action String timerKey = "actionCreate: " + proxy.getActionName(); try { UtilTimerStack.push(timerKey); action = objectFactory.buildAction(proxy.getActionName(), proxy.getNamespace(), proxy.getConfig(), contextMap); } catch (InstantiationException e) { throw new XWorkException("Unable to instantiate Action!", e, proxy.getConfig()); } catch (IllegalAccessException e) { throw new XWorkException("Illegal access to constructor, is it public?", e, proxy.getConfig()); } catch (Exception e) { String gripe; if (proxy == null) { gripe = "Whoa! No ActionProxy instance found in current ActionInvocation. This is bad ... very bad"; } else if (proxy.getConfig() == null) { gripe = "Sheesh. Where'd that ActionProxy get to? I can't find it in the current ActionInvocation!?"; } else if (proxy.getConfig().getClassName() == null) { gripe = "No Action defined for '" + proxy.getActionName() + "' in namespace '" + proxy.getNamespace() + "'"; } else { gripe = "Unable to instantiate Action, " + proxy.getConfig().getClassName() + ", defined for '" + proxy.getActionName() + "' in namespace '" + proxy.getNamespace() + "'"; } gripe += (((" -- " + e.getMessage()) != null) ? e.getMessage() : " [no message in exception]"); throw new XWorkException(gripe, e, proxy.getConfig()); } finally { UtilTimerStack.pop(timerKey); } if (actionEventListener != null) { action = actionEventListener.prepare(action, stack); } }
DefaultActionInvocation類：
protected void createInterceptors(ActionProxy proxy) { // Get a new List so we don't get problems with the iterator if someone changes the original list List<InterceptorMapping> interceptorList = new ArrayList<>(proxy.getConfig().getInterceptors()); interceptors = interceptorList.iterator(); }
action代理類(ActionProxy類)的准備工作完成之后，就開始執行了。最頂部的代碼中就很明確的看的出來(serviceAction方法)。先是根據參數mapping來判斷是否為直接回返。如果不是才去執行action代理類(ActionProxy類)的execute方法。這便是action代理類(ActionProxy類)的主要工作。即是執行action請求。那么讓我們看一下action代理類(ActionProxy類)的execute方法源碼吧。
public String execute() throws Exception { ActionContext nestedContext = ActionContext.getContext(); ActionContext.setContext(invocation.getInvocationContext()); String retCode = null; String profileKey = "execute: "; try { UtilTimerStack.push(profileKey); retCode = invocation.invoke(); } finally { if (cleanupContext) { ActionContext.setContext(nestedContext); } UtilTimerStack.pop(profileKey); } return retCode; }
從紅色的代碼部分我們就知道就是去執行DefaultActionInvocation類實例的invoke方法
DefaultActionInvocation類：
public String invoke() throws Exception { String profileKey = "invoke: "; try { UtilTimerStack.push(profileKey); if (executed) { throw new IllegalStateException("Action has already executed"); } if (interceptors.hasNext()) {//獲得一個攔截器 final InterceptorMapping interceptor = interceptors.next(); String interceptorMsg = "interceptor: " + interceptor.getName(); UtilTimerStack.push(interceptorMsg); try { resultCode = interceptor.getInterceptor().intercept(DefaultActionInvocation.this);//執行攔截器 } finally { UtilTimerStack.pop(interceptorMsg); } } else { resultCode = invokeActionOnly(); } // this is needed because the result will be executed, then control will return to the Interceptor, which will // return above and flow through again if (!executed) { if (preResultListeners != null) { LOG.trace("Executing PreResultListeners for result [{}]", result); for (Object preResultListener : preResultListeners) { PreResultListener listener = (PreResultListener) preResultListener; String _profileKey = "preResultListener: "; try { UtilTimerStack.push(_profileKey); listener.beforeResult(this, resultCode); } finally { UtilTimerStack.pop(_profileKey); } } } // now execute the result, if we're supposed to if (proxy.getExecuteResult()) { executeResult(); } executed = true; } return resultCode; } finally { UtilTimerStack.pop(profileKey); } }
上面的紅色的代碼是這個方法的核心點之一。讓我們看一下紅色代碼做什么？判斷interceptors是否有攔截器。如果沒有就直接執行invokeActionOnly方法。即是執行action類實例對應的方法。如果有就獲得攔截器並執行攔截器(執行intercept方法)。好了。關鍵點就在這個執行攔截器身上。即是執行intercept方法。intercept方法有一個參數就是DefaultActionInvocation類的接口。這個參數讓struts2的AOP思想能夠進行。為什么這樣子講呢？不清楚讀者有沒有想過。為什么這邊判斷攔截器是用if而不是用for 或是 while呢？必竟攔截器不只一個。我們都清楚AOP的目標就是讓業務模塊選擇對應的切面。那么就有可能存在多個攔截器。這也是為什么亮點的原因了。看一下攔截器的代碼就知道了。如下
LoggingInterceptor類：
public String intercept(ActionInvocation invocation) throws Exception { logMessage(invocation, START_MESSAGE); String result = invocation.invoke(); logMessage(invocation, FINISH_MESSAGE); return result; }
攔截器開始的時候，執行相關的攔截器邏輯，然后又重新調用DefaultActionInvocation類的invoke方法。從而獲得下一個攔截器。就是這樣子下一個攔截器又開始執行自己的intercept方法。做了相關的攔截器邏輯之后。又一次重新調用DefaultActionInvocation類的invoke方法。又做了相似的工作。只到沒有了攔截器，執行用戶action類實例的方法並返回結果。有了結果之后，就開始續繼執行當前上一個攔截器的后半部分代碼。直到返回到最開始的攔截器執行后半部分的代碼。