struts2流程及源码分析

其他 2018-11-23 23:54:39 阅读次数: 0

struts 架构图

image.png

分析这个架构图，我们可以从4个部分，也就struts访问的4个阶段的流程来分析

这4个阶段包括：Action映射、Action转发、Action执行、结果返回

首先是Action映射阶段

当请求到来的时候，首先是struts的核心过滤器接收到请求，然后通过ActionMapper进行映射

我们以下图struts配置为例，查看一下struts在处理这个请求阶段的过程：

image.png

在StrutsPrepareAndExecuteFilter源码中，它本质是一个过滤器，核心的代码在doFilter部分，我们把这部分代码copy过来如下：

public void doFilter(ServletRequest req, ServletResponse res, FilterChain chain) throws IOException, ServletException {

        HttpServletRequest request = (HttpServletRequest) req;
        HttpServletResponse response = (HttpServletResponse) res;

        try {
            if (excludedPatterns != null && prepare.isUrlExcluded(request, excludedPatterns)) {
                chain.doFilter(request, response);
            } else {
                prepare.setEncodingAndLocale(request, response);
                prepare.createActionContext(request, response);
                prepare.assignDispatcherToThread();
                request = prepare.wrapRequest(request);
                ActionMapping mapping = prepare.findActionMapping(request, response, true);
                if (mapping == null) {
                    boolean handled = execute.executeStaticResourceRequest(request, response);
                    if (!handled) {
                        chain.doFilter(request, response);
                    }
                } else {
                    execute.executeAction(request, response, mapping);
                }
            }
        } finally {
            prepare.cleanupRequest(request);
        }
    }

判断是否需要struts处理

当请求过来的时候，首先判断是否应该由struts处理这个请求，如果不是那就应该放行

image.png

我们这个请求肯定是要经过struts处理的，所以应该走else部分：

创建数据中心ActionContext

接下来需要关注的是这行

prepare.createActionContext(request, response);

这是干什么呢？从名字上看，就是在创建一个ActionContext数据中心

还记得吗？这个就是那个包含原生servlet 11个域对象还有值栈的一个大容器（本质上就是map）

可以进去看下这部分的源码：

/**
 * 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;
    }
    
    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));
        ctx = new ActionContext(stack.getContext());
    }
    request.setAttribute(CLEANUP_RECURSION_COUNTER, counter);
    ActionContext.setContext(ctx);
    return ctx;
}

在初始化阶段，关键在这里：

image.png

这三行代码，简单来看，第一步就是创建值栈，第二步就是往Context中准备一些数据

最后看第三步，可以看到ActionContext这个数据中心实际上就是ValueStack的Context

增强包装request对象

接下来关注的是91行的这句：

image.png

在还没运行阶段，这个request还是原生的org.apache.catalina.connector.RequestFacade类型

image.png

执行完后就变成了org.apache.struts2.dispatcher.StrutsRequestWrapper类型了，这个就是由struts包装的request对象

image.png

那struts包装是做了哪些事情呢，可以勘测一下StrutsRequestWrapper源码

其实它就包装（增强）了一个方法getAttribute

可以看下这部分的代码：

/**
 * Gets the object, looking in the value stack if not found
 *
 * @param key The attribute key
 */
public Object getAttribute(String key) {
    if (key == null) {
        throw new NullPointerException("You must specify a key value");
    }

    if (disableRequestAttributeValueStackLookup || key.startsWith("javax.servlet")) {
        // don't bother with the standard javax.servlet attributes, we can short-circuit this
        // see WW-953 and the forums post linked in that issue for more info
        return super.getAttribute(key);
    }

    ActionContext ctx = ActionContext.getContext();
    Object attribute = super.getAttribute(key);

    if (ctx != null && attribute == null) {
        boolean alreadyIn = isTrue((Boolean) ctx.get(REQUEST_WRAPPER_GET_ATTRIBUTE));

        // note: we don't let # come through or else a request for
        // #attr.foo or #request.foo could cause an endless loop
        if (!alreadyIn && !key.contains("#")) {
            try {
                // If not found, then try the ValueStack
                ctx.put(REQUEST_WRAPPER_GET_ATTRIBUTE, Boolean.TRUE);
                ValueStack stack = ctx.getValueStack();
                if (stack != null) {
                    attribute = stack.findValue(key);
                }
            } finally {
                ctx.put(REQUEST_WRAPPER_GET_ATTRIBUTE, Boolean.FALSE);
            }
        }
    }
    return attribute;
}

内容很长，但简单来说就是注释上的那么一句话：

Gets the object, looking in the value stack if not found

翻译过来那就是：这个方法会先从原生request域中去找，如果找不到的话，就会往值栈中去找

前面说过ValueStack包含两个部分，一个是ROOT栈部分，一个是context部分（从源码上来看，这个部分就是ActionContext）。

那么拆解开来看，我们可以得到以下结论：

当我们在struts中调用原生的request.getAttribute()方法时：struts会帮我们从以下几个域中依次寻找属性

  1. 原生request域
  2. ValueStack的栈部分
  3. ValueStack的context部分（ActionContext）

我们看一下源码当中这个过程的体现：

image.png

很明显这一步就是从request域中去找，如果找不到就往下：

image.png

上面的那段注释告诉我们，使用request来寻找ActionContext内容是不需要和OGNL表达式一样带#来访问的，并且也不允许（否则会陷入死循环）

简单来说，原生的怎么写就怎么写，不需要管里边的具体实现

ActionMapping

最后它要做的操作就是把请求转换为ActionMapping对象，好方便接下来后期处理，

这个过程简单来说就是把我们访问的url地址

http://localhost/strutsLearn/customer/list

解析成

ActionMapping{name='list', namespace='/customer', method='null', extension='null', params=null, result=null}

这种形式的对象

上面的形式是可以解析出来的情况，但是我们知道每一次请求也肯定有很多静态资源文件，这些都是struts解析不了的，这时候mapping得到的结果就为null

image.png

到这里，也就是我们第一阶段所要完成的任务了，就是通过ActionMapper工具获取ActionMapping对象。

那么再往下，就是把ActionMapping交给下一个阶段往下执行了。

execute.executeAction(request, response, mapping);

核心代理转发阶段——创建ActionProxy

这个方法只是一个中间方法，它再具体调用下一个

dispatcher.serviceAction(request, response, mapping);

在这里，关键部分是try catch语句中：

try {
    UtilTimerStack.push(timerKey);
    String namespace = mapping.getNamespace();
    String name = mapping.getName();
    String method = mapping.getMethod();

    ActionProxy proxy = getContainer().getInstance(ActionProxyFactory.class).createActionProxy(
            namespace, name, method, extraContext, true, false);

    request.setAttribute(ServletActionContext.STRUTS_VALUESTACK_KEY, proxy.getInvocation().getStack());

    // if the ActionMapping says to go straight to a result, do it!
    if (mapping.getResult() != null) {
        Result result = mapping.getResult();
        result.execute(proxy.getInvocation());
    } else {
        proxy.execute();
    }

    // If there was a previous value stack then set it back onto the request
    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);
}

首先是提取ActionMapping中的各种信息：

image.png

接下来就是创建ActionProxy对象了：

ActionProxy proxy = getContainer().getInstance(ActionProxyFactory.class).createActionProxy(
namespace, name, method, extraContext, true, false);

在这里如果深入去看proxy创建过程，其实就包含了根据actionMapping的信息去寻找配置文件struts.xml配置项的过程。这里就不再展开了。

可以看下ActionProxy大概长啥样

image.png

那么创建出来后就需要分派给人去执行了，但是执行分两种情况

image.png

这两种其实都一样，我们这里是第一次初始访问，没有结果返回，因此直接进入的是

proxy.execute();
public String execute() throws Exception {
    ActionContext previous = ActionContext.getContext();
    ActionContext.setContext(invocation.getInvocationContext());
    try {
// This is for the new API:
//            return RequestContextImpl.callInContext(invocation, new Callable<String>() {
//                public String call() throws Exception {
//                    return invocation.invoke();
//                }
//            });

        return invocation.invoke();
    } finally {
        if (cleanupContext)
            ActionContext.setContext(previous);
    }
}

这个方法里，即将进入的就是 invoke 方法了！

return invocation.invoke();

Action执行阶段——拦截器执行

调用这个方法，也就意味着进入第三阶段——Aciton执行阶段了

在这个阶段，我们知道它即将进入执行N多个拦截器，我们进入看看它里面的关键代码：

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();
}

其中interceptors被定义成拦截器容器的迭代器

protected Iterator<InterceptorMapping> interceptors;

这个拦截器容器就是Proxy阶段传过来的

这其中一行代码第一眼看上去确实让人奇怪：

if (interceptors.hasNext())

通常对迭代器的循环应该是while这里为什么变成if 呢

先不管，继续往下看：

首先是获取拦截器容器中的拦截器和拦截器名称：

final InterceptorMapping interceptor = interceptors.next();
String interceptorMsg = "interceptor: " + interceptor.getName();
UtilTimerStack.push(interceptorMsg);

这个拦截器的类型是：

image.png

Exception拦截器

和struts-default配置拦截器栈的第一个拦截器是一样的：

image.png

到这里，看似真的是要遍历

接下来断定肯定去执行这个拦截器里的内容

resultCode = interceptor.getInterceptor().intercept(DefaultActionInvocation.this);

获取到具体的拦截器，调用拦截器的intercept方法，注意到的是这里把this作为参数穿进去了。

我们看看这里面做了什么

结果一进来就做了这么一件事情：

result = invocation.invoke();

这时候就得出结论了：

invocation的invoke方法调用interceptor的intercept方法
接着反过来interceptor的intercept方法又调回invocation的invoke方法

这不就形成了另一种形式的递归吗？

所以接下来又回到invocation的invoke方法执行

那个迭代器的结束条件if

if (interceptors.hasNext())

就没什么奇怪了。

但是为什么要这么设计递归了，普通的遍历不是挺好的吗？接着往下看。

执行完一轮后，再看拦截器的名字：

image.png

就是Exception的下一个拦截器alias

这个拦截器的invoke方法进行了比较多的复杂处理，但是不管结果如何，最终都会调用：

return invocation.invoke();

@Override public String intercept(ActionInvocation invocation) throws Exception {
    ....... 此处省略n行代码
    return invocation.invoke();
}

到这里，这下明白了这么设计的用意何在了吧。

每个拦截器的invoke方法执行的方式不一样，通过这种间接递归的方式就能把所有不同功能的器件全部执行一遍了。

看完后，不得不说，这种设计的精妙之处啊

Action执行

拦截器执行完成后接下来就到：

resultCode = invokeActionOnly();

只执行Action了

接下来可以推测，它就是去找到我们自己写的Action中的类去执行去了。

跳出这个过程，我们可以看到resultCode返回结果：

image.png

那么可以猜想，接下来就会拿着这个结果根据我们定义的配置文件处理去，也就是进入我们所说的第四阶段了

接下来就会去执行结果处理函数

// now execute the result, if we're supposed to
if (proxy.getExecuteResult()) {
    executeResult();
}

好了，到这里先告一段落，关于后续的结果处理函数后期再补充吧

猜你喜欢

转载自www.cnblogs.com/autom/p/10010214.html
今日推荐
《美国对全球网络空间安全与发展的威胁和破坏》报告发布
火速冲上 GitHub 热榜 —— 开源编程语言、框架哪有这么可爱？
北京人形机器人创新中心发布全球首个纯电驱拟人奔跑的全尺寸人形机器人“天工”
LFOSSA 源来如此公开课 | 掌握云原生未来：CNCF 认证全面攻略与备考秘籍
周排行
循环神经网络（rnn）讲解
Tigao教程四：单独的关节运动
金蝶K3WISE15.0-注册套打教程
如何在Mac上配置Kubernetes
Android应用结束自身进程的方法
SpringMVC学习 十三 拦截器栈
中国驻洛杉矶总领馆举行新春招待会
HttpClient get post 发送
11 - three.js 笔记 - 绘制三维字体模型
Mysql递归获取某个父节点下面的所有子节点和子节点上的所有父节点
每日归档
更多
2024-05-01(4)
2024-04-30(1)
2024-04-29(40)
2024-04-28(0)
2024-04-27(56)
2024-04-26(39)
2024-04-25(22)
2024-04-24(36)
2024-04-23(26)
2024-04-22(39)

代码天地 © 2018 codetd.com

境外服务器   最新电视剧2022