tomcat4标准包装器StandardWrapper

Posted 2023-05-12

参考技术A 对于Mapper,其有一个默认实现为StandardContextMapper

在StandardContext的start()方法中，这个默认的Mapper通过addDefaultMapper()方法会被初始化，然后通过Container的addMapper()方法加入到Container中。

对于一个实现了SingleThreadModel接口的servlet，其目的是保证servlet 一次只能有一个请求，也即保证不会有两个线程同是使用 servlet
的 service 方法，该接口并不能避免同步而产生的问题，如访问静态
类变量或该 servlet 以外的类或变量。

在tomcat中，Wrapper容器的父容器为Context，Context的默认实现为StandardContext，其Pipeline的basic Valve为StandardContextValve，当一个请求被Context的invoke方法接收到的时候，根据Pipeline的处理流程，最终交给了StandardContextValve的invoke(Request request, Response response,ValveContext valveContext)方法来处理，而StandardContextValve是通过Context.map()方法来找到对应的Wrapper，Context如何找Wrapper这里略去，比较简单，主要看看Wrapper处理请求的过程，在tomcat中，Wrapper的默认实现为StandardWrapper，其Pipeline的basic Valve为StandardWrapperValve，这里就从这里开始分析：

不管是SingleThreadModel的Servlet还是非SingleThreadModel的Servlet，其创建的方法都为loadServlet()

在servlet初始化的时候，其需要一个参数为ServletConfig，先看下类图：

StandardWrapperFacade是一个包装类，内部对于ServletConfig的实现由StandardWrapper来完成，这里只看一下StandardWrapper是如何获取ServletContext 的：

servlet运行的上下文环境由Context创建，从这里可以看到，一个单独的wrapper是不能单独部署的，单独部署的Wrapper是没法获取到servletcontext的。在StandardContext中的getServletContext方法中创建了servletcontext。

在获取到servlet实例后，StandardWrapperValve继续对请求进行相关处理

在分析ApplicationFilterChain的创建过程之前，先了解下filter关联的类图

这个构建ApplicationFilterChain的逻辑还是比较简单的，主要看这句：

我们在web.xml中配置的filter，如

都会被先转化为FilterDef和FilterMap，这些FilterDef和FilterMap被保存在Context中，在Context的启动过程中会被转化为ApplicationFilterConfig：
StandardContext.start():

StandardContext.filterStart():

所以StandardContext找FilterConfig的方式就比较简单了：

在获取到ApplicationFilterChain之后，StandardWrapperValve.invoke()中紧跟着就调用其doFilter方法,ApplicationFilterChain中doFilter最终调用了internalDoFilter()方法：

ApplicationFilterChain.internalDoFilter()

从这段逻辑中可以看出，在自己定义拦截器的时候，如果最后没有调用ApplicationFilterChain.doFilter()方法，那后续所有的filter和servlet的service()都是没有机会被执行的，从而达到了拦截的目的。

为自定义 C 库分发 CFFI 包装器

【中文标题】为自定义 C 库分发 CFFI 包装器

【英文标题】：Distributing a CFFI wrapper for a custom C lib

【发布时间】：2021-10-17 04:43:35

【问题描述】：

我已经构建了一个包含自定义 C 代码的库，并考虑了构建共享库作为 ASDF 加载的一部分的最佳方式。 makefile 针对各种操作系统进行了条件化，因此它可以像uiop:run-program ... 一样简单，但我想我会在这里询问是否有更标准的习语。

因为 C 代码是特定于这个应用程序的，它不能通过包管理器获得，并且必须专门为每个用户的机器构建。我可以记录手动构建，但如果我可以为用户顺利进行操作，我会的。我注意到 Python 似乎有某种为他们的 CFFI 构建库的自动化方式，我想知道是否有适合 CL 的东西。

【参考方案1】：

对于我自己的问题的答案：似乎既没有事实上的方法（基于对 github asd 文件的搜索），也没有在ASDF best practices 中确定的方法，尽管有一些想法从该文档中收集。

我将把我的实现作为这个用例的建议惯用语，以及一些可能的替代方案。希望这里的一些 ASDF 专家能够纠正任何误解。

;; Define a makefile as a type of source file for the system
(defclass makefile (source-file) ((type :initform "m")))

;; tell ASDF how to compile it
(defmethod perform ((o load-op) (c makefile)) t)
(defmethod perform ((o compile-op) (c makefile))
  (let* ((lib-dir (system-relative-pathname "cephes" "scipy-cephes"))
         (lib (make-pathname :directory `(:relative ,(namestring lib-dir))
                             :name "libmd"
                             :type #+unix "so" #+(or windows win32) "dll"))
     (built (probe-file (namestring lib))))
    (if built
      (format *error-output* "Library ~S exists, skipping build" lib)
      (format *error-output* "Building ~S~%" lib))
    (unless built
      (run-program (format nil "cd ~S && make" (namestring lib-dir)) :output t))))

(defsystem "cephes"
  :description "Wrapper for the Cephes Mathematical Library"
  :version      (:read-file-form "version.sexp")
  :license "MS-PL"
  :depends-on ("cffi")
  :serial t
  :components ((:module "libmd"
                :components ((:makefile "makefile")))
               (:file "package")
               (:file "init")
               (:file "cephes")))

这在 MS Windows 和 UNIX 上都可以正常工作。给perform加一个方法好像是github上最常用的方法了。

另一种方法可能是使用build-op，如building a system 中所述。说明

某些系统提供的操作既不加载在当前 图像，也没有测试。无论系统打算使用哪种操作 与，您可以将其用于：

(asdf:make :foobar)

这将调用 build-op，而 build-op 又取决于 系统的构建操作（如果已定义）或加载操作（如果未定义）。 因此，对于希望您加载它们的普通 Lisp 系统， 以上将等同于 (asdf:load-system :foobar)，但对于其他 Lisp 系统，例如一个创建 shell 命令行可执行文件的程序， (asdf:make ...) 将做 Right Thing™，无论 Right Thing™ 是。

向我建议，这与构建 C 库的想法相当接近，并且可以很好地映射到使用 makefile 和 asdf:make 命令的心理模型。虽然我没有找到太多这样的例子，但从技术上讲，我们将 C 库加载到现有图像中。

可以重新考虑的另一点是检测现有共享库以避免重建。如果共享库存在，make 将避免重新编译，但仍会再次调用链接器。这会导致错误，因为它在使用时无法写入共享库，至少在 MS Windows 上是这样。 ASDF 示例使用 Lisp 代码来检测库的存在并避免重新编译，但替代方法可能是使用 output-files。

ASDF 文档对 output-files 的目的有点混乱，没有任何例子可以说明他们的意图，但在 creating new operations 的手册部分中，我们有：

output-files 如果你的 perform 方法有任何输出，你必须定义一个 这个函数的方法。让 ASDF 确定 执行操作谎言。

这表明定义共享库（libmd.so 或 libmd.dll）是在 output-files 已存在的情况下避免重新编译的推荐方法。

最后，C 库可以被视为辅助系统，在这种情况下为cephes/libmd，并添加到主系统的:depends-on 子句中。 other secondary systems 部分演示了使用 build-op 以这种方式构建可执行文件。除了这是构建可执行文件和硬编码“.exe”这一事实之外，它似乎很好地映射到用例：

要构建一个可执行文件，请按如下方式定义一个系统（在本例中，它是 一个辅助系统，但它也可以是一个主系统）。你会 能够通过评估创建可执行文件 foobar-command (asdf:make :foobar/executable):

(defsystem "foobar/executable"
  :build-operation program-op
  :build-pathname "foobar-command" ;; shell name
  :entry-point "foobar::start-foobar" ;; thunk
  :depends-on ("foobar")
  :components ((:file "main")))

build-pathname 给出了可执行文件的名称； .exe 类型将 在 Windows 上自动添加。

我没有使用这种方法，因为辅助系统看起来几乎与现在的主系统一模一样，但会稍微难以理解。