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

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

下面是一次过滤过程中过滤器相关类的堆栈：
[img]http://dl.iteye.com/upload/attachment/226369/a53d1498-3675-3e1a-b227-9bd45650ede1.jpg[/img]
其流程简单来说是：某个类处理过滤器目标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成员传入的。
[img]http://dl.iteye.com/upload/attachment/226371/5d389bc9-b7db-3fe3-b20a-7c2b4dbc5955.jpg[/img]
最后，在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进行处理。