初识Webx 2

Posted 2020-07-19 流年素心

初识Webx 1: http://www.cnblogs.com/lddbupt/p/5547189.html

 

Webx Framework负责完成一系列基础性的任务. 比如系统初始化和响应请求.

系统初始化: 初始化Spring容器, 初始化日志系统.

响应请求: 增强request/response/session的功能, 提供pipeline流程处理机制, 异常处理, 开发模式.

Webx Framework提供了一个可剪裁、可扩展的处理WEB请求基本框架。它所提供的基本功能事实上是每个WEB框架都需要用到的。Webx Framework为进一步实现WEB框架提供了坚实的基础。

Webx的初始化

初始化级联的Spring容器

Webx Framework将负责创建一组级联的Spring容器结构。Webx所创建的Spring容器完全兼容于Spring MVC所创建的容器，可被所有使用Spring框架作为基础的WEB框架所使用。

WebxContextLoaderListener是由Spring中的ContextLoaderListener派生的, 可代替后者用来初始化Spring容器.

Webx Framework将会自动搜索/WEB-INF目录下的XML配置文件，并创建下面这种级联的spring容器。

注意: 如果不希望把你的应用分成多个小应用模块，那么，你还是需要配置至少一个小应用模块（子容器）。

初始化日志系统

Webx Framework使用SLF4J作为它的日志框架。因此Webx Framework理论上支持所有日志系统。然而目前为止，它只包含了log4j和logback这两种日志系统的初始化模块.

LogConfiguratorListener会根据你当前应用所依赖的日志系统（通常配置在maven project中），来自动选择合适的日志配置文件。

• 假设你的应用依赖了logback的jar包，那么listener就会查找/WEB-INF/logback.xml，并用它来初始化logback；
• 如果你的应用依赖了log4j的jar包，那么listener也会很聪明地查找/WEB-INF/log4j.xml配置文件。
• 假如以上配置文件不存在，listener会使用默认的配置 —— 把日志打印在控制台上。
• Listener支持对配置文件中的placeholders进行替换。
• Listener支持同时初始化多种日志系统。

Webx响应请求

当Webx Framework接收到一个来自WEB的请求后, 它会封装成更易使用的RequestContext对象(增强request, response, session的功能), 然后, 路由到子应用, 调用相应的子应用的pipeline, 进一步处理.

如果上述过程出现异常,则会触发Webx Framework处理异常.

增强request, response, session的功能

Request contexts服务.  利用HttpServletRequestWrapper和HttpServletResponseWrapper对request和response对象进行包装，以实现新的功能。

Request contexts所有的功能都是可配置、可扩展的 —— 它是基于SpringExt的扩展机制。

Request contexts所增加的功能对于所有的基于标准Servlet API的应用都是透明的 —— 这些应用根本不需要知道这些扩展的存在。例如，假如你在request contexts服务中配置了增强的session框架，那么所有通过标准的Servlet API取得session的应用，都将获得新功能.

[注入特殊对象]

在这个例子中，LoginAction类可以是一个singleton。一般来说，你不能把request scope的对象，注入到singleton scope的对象中。但你可以把HttpServletRequest、HttpServletResponse和HttpSession对象注入到singleton对象中。为什么呢？原来，Request contexts服务对这几个常用对象进行了特殊处理，将它们转化成了singleton对象。

如果没有这个功能，那么我们就不得不将上例中的LoginAction配置成request scope。这增加了系统的复杂性，也成倍地降低了性能。而将LoginAction设置成singleton，只需要在系统启动时初始化一次，以后就可以快速引用它。 ????线程不安全???

Pipeline流程机制

Webx Framework中的pipeline可以控制处理请求的流程的走向。

Webx Framework并没有规定管道的内容 —— 定制管道是应用开发者的自由。然而Webx Framework提供了一系列通用valves，你可以使用它们.

异常处理机制

开发模式工具

Webx Framework提供了一个开关，可以让应用运行于“生产模式（Production Mode）”或是“开发模式（Development Mode）” 。

在开发模式下，会有一系列不同于生产模式的行为。

• 不同的主页 —— 在开发模式的主页中，可以查看和查询系统内部的信息。
• 不同的详细出错页面。
• 开发模式下，可展示所有可用的schemas。
• 开发模式下，可以查阅容器内部的信息。譬如全部beans的定义,查看配置文件,跟踪resources的装载过程等等.

事实上，Webx Framework提供了一套专用的内部框架，使你可以往开发模式中添加更多的开发工具。

Webx Framework提供了一个接口：ProductionModeAware。Spring context中的beans，如果实现了这个接口，就可以感知当前系统的运行模式，从而根据不同的模式选择不同的行为.

响应和处理请求的更多细节

当一个HTTP请求到达时，首先由WebxFrameworkFilter接手这个请求.

“passthru略过”和“excludes排除”的区别在于，如果一个servlet或filter接手被webx passthru的请求时，它们还是可以访问到webx的部分服务，包括：

• RequestContext服务，例如：解析参数、解析upload请求、重写请求、设置字符集编码和区域、基于cookie的session等。
• 开发模式及工具。
• 异常处理。
• 共享webx的spring容器。

也就是说，对于一个被passthru的请求，webx的行为更像是一个普通的filter。而“排除”则不同，如果一个请求被“排除”，webx将会立即放弃控制，将请求交还给服务器。接手控制的servlet或filter将无法访问webx一切的服务。

为什么使用filter而不是servlet呢？传统的WEB框架的控制器一般都是用servlet实现的。原因是：

• Filter可以“返还控制” —— 上面的配置文件直接把“/*”映射到webx filter中，这意味着webx接管了这个应用的所有请求。静态页面和资源怎么办？没关系，如果webx发现这个请求不应该由webx来处理，就会把控制“返还”给原来的控制器 —— 可能是另一个filter、servlet或者返回给servlet引擎，以默认的方式来处理。而Servlet是不具备“返还控制”的机制的。
• Servlet/Filter mapping的局限性 —— 标准的servlet引擎将URL映射到filter或servlet时，只支持前缀映射和后缀映射两种方式，非常局限。而实际情况往往复杂得多。Webx建议将所有请求都映射给webx来处理，让webx对请求做更灵活的映射。

定制Webx Framework

WebxRootController是被所有子应用所共享的逻辑。 假如你想创建一种新的WEB框架，可以自己定义一个新的WebxRootController的实现。这个方案非常适合作为一个新Web框架的起点。

创建自己的WebxRootController。最简便的方法是：扩展AbstractWebxRootController，免去了创建Servlet/Filter、初始化Spring容器、处理request、response等繁杂事务，并且完全支持SpringExt的所有功能，此外还包含了错误处理、开发模式等Webx Framework中的一切便利。

Webx Framework默认的WebxController是调用pipeline。假如你不想用pipeline，而希望实现自己的针对子应用的逻辑，那么最简单的方法就是实现自己的WebxController或者扩展AbstractWebxController。

 

参考文献

http://www.openwebx.org/

http://openwebx.org/docs/webxframework.html#d0e1272