sakai中,请求url到tool对象的照射

sakai中,请求url到tool对象的映射
sakai中,请求url到tool对象的映射。

下面是一次过滤过程中过滤器相关类的堆栈:
sakai中,请求url到tool对象的照射
其流程简单来说是:某个类处理过滤器目标servlet。
从堆栈上看,涉及到5个类:ActiveToolComponent(“某个类处理”)
ApplicationDispatcher, ApplicationFilterChain, AdminSiteAction(目标servlet)
有几个问题:
1、整个过程是同步的函数调用还是类似于异步的消息机制?
整个过程比较简单,只是一些简单函数调用而已,变换较多,所以貌似比较复杂,同步函数调用。
2、过滤器怎么知道该调用哪个servlet?
ActiveToolComponent持有一个servletcontext,在初始化时注入。
然后通过m_servletContext.getNamedDispatcher(getId());
得到一个实现了RequestDispatcher接口的类,即ApplicationDispatcher。
注意,getNamedDispatcher方法接受一个servlet名称参数,这个名称是在部署描述符中﹤servlet-name﹥元素指定的那个名称。这里传入了一个getId()参数,就能保证得到一个具体的servlet类,这个类可能是通过IOC 容器注入的。
等效的看,servlet已经由ActiveToolComponent传到了RequestDispatcher。
接下来是如何传到ApplicationFilterChain中:
从以下第二行可以看出filterChain的工厂是将ApplicationDispatcher类中的servlet成员传入的。
sakai中,请求url到tool对象的照射
最后,在filterChain中,过滤链中的所有函数传递完后,取出目标servlet,即AdminSiteAction。
3、补充
在本例中ActiveToolComponent通过调用forward()进行调用,过滤去进行了处理,是因为在web.xml 中声明了<dispatcher>FORWARD</dispatcher>
4、那么,为什么这么做?
至少有一种原因:为了解耦。如第二点中分析,目标servlet在启动初始化的时候注入(与getId()的值绑定),getId是ActiveToolComponent的一个属性,所以问题变为构造一个ActiveToolComponent的子类。这个过程发生在Toolhandler.java中。
5、其他
RequestFilter.java 作用。主要参考sakai_request.doc以及注释。
一般情况下,RequestFilter会过滤sakai的所有tool请求,通过写cookie维护session;如果是文件上传,就用Apache commons-fileuplaod进行处理。