文档章节

Play源码深入之三:一次访问的前半生-请求

奋斗到天明
 奋斗到天明
发布于 2015/08/27 18:12
字数 1144
阅读 359
收藏 0

接着 上篇,play初始化完成之后,第一个请求来到了PlayHandler中,我们看PlayHandler如何处理。 Netty调用play.server.PlayHandler:messageReceived()方法,play将netty的httprequest转化成自己的Http.Request对象。

...
// Plain old HttpRequest
try {
    final Request request = parseRequest(ctx, nettyRequest, messageEvent);

    final Response response = new Response();
    Http.Response.current.set(response);

    // Buffered in memory output
    response.out = new ByteArrayOutputStream();

    // Direct output (will be set later)
    response.direct = null;

    // Streamed output (using response.writeChunk)
    response.onWriteChunk(new Action< Object >() {

        public void invoke(Object result) {
            writeChunk(request, response, ctx, nettyRequest, result);
        }
    });

    // Raw invocation
    boolean raw = Play.pluginCollection.rawInvocation(request, response);
    if (raw) {
        copyResponse(ctx, request, response, nettyRequest);
    } else {

        // Deleguate to Play framework
        Invoker.invoke(new NettyInvocation(request, response, ctx, nettyRequest, messageEvent));

    }

} catch (Exception ex) {
  Logger.warn(ex, "Exception on request. serving 500 back");
    serve500(ex, ctx, nettyRequest);
}
...

构建了Http.Response对象。然后发出原始调用事件rawInvocation,每个插件plugin可以处理这个请求,并决定是否放弃后续处理直接返回Response。如果所有插件处理后没有中断,则交与NettyInvocation处理。 

这时从Eclipse的Debug面板中可以看到,NettyInvocation已经是第三个线程了。 NettyInvocation继承了Invoker.Invocation,在run()方法调用了Invoker.Invocation:run()方法,所以主体就在Invoker.Invocation:run()中

...
public static abstract class Invocation implements Runnable {
    ...
    public void run() {
        if (waitInQueue != null) {
            waitInQueue.stop();
        }
        try {
            preInit();
            if (init()) {
                before();
                boolean withinFilterFctFound = this.withinFilter(new play.libs.F.Function0() {
                    public Void apply() throws Throwable {
                        execute();
                        return null;
                    }
                });
                // No filter function found => we need to execute anyway( as before the use of withinFilter )
                if(!withinFilterFctFound){
                    execute();
                }
                after();
                onSuccess();
            }
        } catch (Suspend e) {
            suspend(e);
            after();
        } catch (Throwable e) {
            onException(e);
        } finally {
            _finally();
        }
    }
    ...
}
...

主体中,通过init()方法初始化了调用相关的参数reqeust/response/scope.param等等的current线程变量。

然后Router负责检查请求的request路径是否在route配置中,是否为静态文件请求。play.mvc.ActionInvoker:resolve()中负责处理调用应用Action方法的初始化,包括路由的匹配、Controller类、方法等。

在getActionMethod方法中,我们可以看到play给每个不以controllers开头的请求路径加上了 controllers.。所以controller就必需写在controllers中了。

...
    public static Object[] getActionMethod(String fullAction) {
        Method actionMethod = null;
        Class controllerClass = null;
        try {
            if (!fullAction.startsWith("controllers.")) {
                fullAction = "controllers." + fullAction;
            }
   ...

init结束。在主体before()触发beforeInvocation事件后,play开始调用各个插件的过滤器处理请求。其中事务处理过滤器就写在了JPAPlugin中。

...
        private boolean withinFilter(play.libs.F.Function0 fct) throws Throwable {
            boolean withinFilterFctFound = false;
            for (PlayPlugin plugin : Play.pluginCollection.getEnabledPlugins()) {
                if (plugin.getFilter() != null){
                    withinFilterFctFound = true;
                    plugin.getFilter().withinFilter(fct);
                }
            }
            return withinFilterFctFound;
        }
        ....

如果请求的方法被NoTransaction注解后,就会不会开启事务。而在开启了事务后,JPA回调play.libs.F.Function0匿名内部类中的apply方法,从而调用execute处理请求。

public class JPA {
    ...
    public static  T withinFilter(F.Function0 block) throws Throwable {
        if(InvocationContext.current().getAnnotation(NoTransaction.class) != null ) {
            //Called method or class is annotated with @NoTransaction telling us that
            //we should not start a transaction
            return block.apply();
        }

        boolean readOnly = false;
        String name = DEFAULT;
        Transactional tx = InvocationContext.current().getAnnotation(Transactional.class);
        if (tx != null) {
            readOnly = tx.readOnly();
        }
        PersistenceUnit pu = InvocationContext.current().getAnnotation(PersistenceUnit.class);
        if (pu != null) {
            name = pu.name();
        }

        return withTransaction(name, readOnly, block);
    }
    ...

    public static  T withTransaction(String dbName, boolean readOnly, F.Function0 block) throws Throwable {
        ...
        for (String name : emfs.keySet()) {
            EntityManager localEm = JPA.newEntityManager(name);
            JPA.bindForCurrentThread(name, localEm, readOnly);

            if (!readOnly) {
                localEm.getTransaction().begin();
            }
        }

        T result = block.apply();   
        ...
    }
    ...
}

在做了如此多的准备工作之后,play.mvc.ActionInvoker中invoker方法,终于要调用我们应用中route文件对应的Controller.action方法了。

public static void invoke(Request request, Http.Response response) {
    ...
    Play.pluginCollection.beforeActionInvocation(actionMethod);

    // Monitoring
    monitor = MonitorFactory.start(request.action + "()");

    // 3. Invoke the action
    try {
      // @Before
      handleBefores(request);

      // Action

      Result actionResult = null;
      String cacheKey = null;

      // Check the cache (only for GET or HEAD)
      if ((request.method.equals("GET") || request.method.equals("HEAD")) && actionMethod.isAnnotationPresent(CacheFor.class)) {
          cacheKey = actionMethod.getAnnotation(CacheFor.class).id();
          if ("".equals(cacheKey)) {
              cacheKey = "urlcache:" + request.url + request.querystring;
          }
          actionResult = (Result) play.cache.Cache.get(cacheKey);
      }

      if (actionResult == null) {
          ControllerInstrumentation.initActionCall();
          try {
              inferResult(invokeControllerMethod(actionMethod));
          } catch(Result result) {
              actionResult = result;
              // Cache it if needed
              if (cacheKey != null) {
                  play.cache.Cache.set(cacheKey, actionResult, actionMethod.getAnnotation(CacheFor.class).value());
              }
          } catch (InvocationTargetException ex) {
              ....
          }
      }
    ...
}

首先,play发出调用前的事件beforeActionInvocation,VolidationPlugin响应,进行校验工作。 

然后,处理@before注解。 

再是,正式处理请求,这是也能看到play被人诟病的基于异常的返回机制。

而参数的绑定就在getActionMethodArgs中,先对请求参数进行了一次重构,形成一棵树状对象。

public static Object[] getActionMethodArgs(Method method, Object o) throws Exception {
        ...
        
        for (int i = 0; i < method.getParameterTypes().length; i++) {
            ...

            rArgs[i] = Binder.bind(
                        root,
                        paramsNames[i],
                        method.getParameterTypes()[i],
                        method.getGenericParameterTypes()[i],
                        method.getParameterAnnotations()[i],
                        new Binder.MethodAndParamInfo(o, method, i + 1));
        }

        CachedBoundActionMethodArgs.current().storeActionMethodArgs(method, rArgs);
        return rArgs;
    }

在play.data.binding.Binder:bind()方法中,我们可以看见,play再次发出了绑定事件,这次也就JPA响应,用Hibenate加载域模型对象。

public static Object bind(RootParamNode parentParamNode, String name, Class<?> clazz, Type type, Annotation[] annotations, MethodAndParamInfo methodAndParamInfo) {
    ...

    if (paramNode != null) {

        // Let a chance to plugins to bind this object
        result = Play.pluginCollection.bind(parentParamNode, name, clazz, type, annotations);
        if (result != null) {
            return result;
        }

        result = internalBind(paramNode, clazz, type, bindingAnnotations);
    }

    ...
}

在invokeWithContinuation方法中,终于看到了 result = method.invoke(instance, realArgs);这是Controller.action()方法的invoke,其实正常情况result没什么用,因为返回结果都是异常,result根本没得收。

static Object invokeWithContinuation(Method method, Object instance, Object[] realArgs) throws Exception {
        ...
        try {
            pStackRecorder.isRestoring = !pStackRecorder.isEmpty();

            // Execute code
            result = method.invoke(instance, realArgs);

            ...
        } finally {
            pStackRecorder.deregisterThread(old);
        }
        return result;
    }

method.invoke就已经进入应用程序了,而到此就是一个访问的前半生——请求。

© 著作权归作者所有

共有 人打赏支持
奋斗到天明
粉丝 18
博文 112
码字总数 82707
作品 0
昌平
程序员
Play源码解析计划

最近有想法看看Play的源码,以提高自己的编码水平。之前都是东看看,西看看。最后看来去却好像无所大成。有人说过,伤敌十指,不如断敌一指,于是我有开始了学习之路。 原计划是采用1.2.3版本...

刀狂剑痴
2015/08/27
143
0
Play源码深入之二:Play应用启动时框架的初始化

接着上篇在python的辅助下,理理输入启动命令之后,play框架进行的初始化工作。 application.py中的javacmd方法中就有play.server.Server。 def javacmd(self, javaargs, cp_args=None, clas...

奋斗到天明
2015/08/27
0
0
Play源码深入之四:一次访问的后半生-响应

在处理了我们应用的代码之后,就会再次进入Play框架的范围,我们就接着说下一个请求的下半生。 在Controller中定义一系列的render方法: 可以对应到play.mvc.results包中各种Render开头的类:...

奋斗到天明
2015/08/27
0
0
Play框架拾遗之三:模板引擎

1、模板语法 用表达式时,如下使用时,只有client不为null的情况下,才进行client.name的输出。 <h1>Client ${client?.name}</h1> 在应用中,模板引擎默认对所有的动态表达式进行转义,以此来...

奋斗到天明
2015/08/27
0
0
Play源码深入之五:Job模块的原理

先看play.jobs.JobsPlugin。 public void onApplicationStart() { int core = Integer.parseInt(Play.configuration.getProperty("play.jobs.pool", "10")); executor = new ScheduledThread......

刀狂剑痴
2015/08/27
810
0

没有更多内容

加载失败,请刷新页面

加载更多

下一页

MySQL 乱七八糟的可重复读隔离级别实现

MySQL 乱七八糟的可重复读隔离级别实现 摘要: 原文可阅读 http://www.iocoder.cn/Fight/MySQL-messy-implementation-of-repeatable-read-isolation-levels 「shimohq」欢迎转载,保留摘要,谢...

DemonsI
54分钟前
2
0
Spring源码阅读——2

在阅读源码之前,先了解下Spring的整体架构: 1、Spring的整体架构 1. Ioc(控制反转) Spring核心模块实现了Ioc的功能,它将类与类之间的依赖从代码中脱离出来,用配置的方式进行依赖关系描...

叶枫啦啦
今天
1
0
jQuery.post() 函数格式详解

jquery的Post方法$.post() $.post是jquery自带的一个方法,使用前需要引入jquery.js 语法:$.post(url,data,callback,type); url(必须):发送请求的地址,String类型 data(可选):发送给后台的...

森火
今天
0
0
referer是什么意思?

看看下面这个回答(打不开网页可以把网址复制到搜索栏): https://zhidao.baidu.com/question/577842068.html

杉下
今天
1
0
使用U盘安装CentOS-解决U盘找不到源

1. 使用UltraISO制作CentOS安装盘 如果需要安装带界面的系统,为保证安装顺利,可选择Everything版本的ISO制作安装盘。 2. 在BIOS中选择使用U盘安装 系统启动后,进入安装选择界面,其中有三...

Houor
今天
1
0

没有更多内容

加载失败,请刷新页面

加载更多

下一页

返回顶部
顶部