读Ofbiz源码笔记 之 请求控制篇

读Ofbiz源码笔记（一）

——请求控制篇

该笔记基于Ofbiz10.04.02解读，系个人阅读Ofbiz源码记录所得，格式不太雅观，可作为阅读Ofbiz源码时的手册，这是第一篇后续会继续阅读写作，其中难免有错误部分望指正。

该篇主要讲解控制请求的流程，以及其中的难点、重点。

GuHao

Email：g.guhao@https://www.360docs.net/doc/b913316375.html,

2012.08.08

1.Web.xml

context-param：上下文参数

filter：过滤器—putAllInitParametersInAttributes、getDelegator、getDispatcher等

listener：监听器（以上这些都要简单浏览一遍）

servlet：核心控制器，重点看这个（ControlServlet.java）

2.ControlServlet.java

1.1.init();初始化

1.1.1.configureBsf();

向BSFManager注册beanshell、javascript、simplemethod的解析类；

1.1.

2.getRequestHandler();

初始化RequestHandler对象，其中包括ControllerConfig（解析controller.xml中include、handlermap，viewmap等，把所有的

request-map解析称RequestMap对象，存放到requestMapMap中）、ViewFactory（实例化各ViewHandler的处理类，放到viewFactory的

handlers中，以备后面展现view之用）、EventFactory（和viewfactory

处理方法类似，作用是实例化controller.xml中所有的handler的

EventHandler的实现类，如JavaEventHandler、ServiceEventHandler

等）；

1.2.doGet()—>doPost()；

1.2.1.request、response的常规设置

request.setCharacterEncoding()，response.setContentType()，response.setCharacterEncoding()

1.2.2.pushUserIdentifier

如果请求访问的用户已登录，把用户放到curValList中第一位，再使用userIdentifierStack（ThreadLocal）存放curValList，userIdentifierStack 既存放当前登陆用户

1.2.3.make security and delegator available in the request

for convenience,and necessity with event handlers,make security and delegator available in the request:try to get it from the session first so that we can have a delegator/dispatcher/security for a certain user if desired

为了方便把一些常用的变量放到session/request中

1.2.4.new ServletContextHashModel()

实例化ServletContextHashModel得到实例化对象ftlServletContext，并存放到request中

1.2.5.VisitHandler.getVisitor(request,response);

判断session中是否存在，如没有获取cookie中的cookieVisstorId 再根据cookieVisstorId去数据库中检索出相应的Visitor对象，如若还是没有则创建Visitor对象保存DB，写入cookie、保存至session

1.2.6.pushSessionIdentifier

与pushUserIdentifier的编程方式一样，但这个是用来存放所有在线用

户的包含未登录的

3.RequestHandler.java

3.1.requestHandler.doRequest

3.1.1.对访问请求做一些安全校验，比如请求是否存在、不安全的

表单数据提交到安全的请求

3.1.2.callRedirect();

根据请求的secure、requestMap.securityHttps(controller.xml中request-map的https)和forceHttpSession(web.xml)等因素makeUrl(即http与https的转换)，然后执行callRedirect()重定向（备注：此处的重定向不是真的意义上的重定向，requestAttribute中的内容我们还是需要的，但是sendRedirect之后将会丢失，所以在sendRedirect之前先把

requestAttribute用一个变量_REQ_ATTR_MAP_存放到session中，至于这里存放的技巧，看源码），重新回到最初的流程走一遍，重新makeUrl（包括对请求是否为爬虫蜘蛛的一些校验）之后的请求将不会在被判断执行

callRedirect();

3.1.3._FIRST_VISIT_EVENTS_

如果是首次访问则执行controller.xml中的firstvisit内的events，至于执行EventHandler.invoke()，这里简单的讲解一种JavaEventHandler

的invoke方法，通过传入controller.xml文件中event的path值（既具

体event处理类的路径），然后利用ClassLoader的方式加载Event处理类，在通过getMethod().invoke()方法执行event的invoke得到事件处理的返

回值，用过Ofbiz的都知道该返回值是String（详细代码请阅读JavaEventHandler.java）；执行完firstVisitEvents判断执行是否成功（既返沪"success"），否则抛出异常，执行成功在session中做记录complete。_FIRST_VISIT_EVENTS_的设计有点不用我多说，应该都明白的。

3.1.

4.执行pre-processor

执行controller.xml中pre-processor内的所有event，但这个是每次访问任意event都执行，所以执行完成之后没有记录到session中这一步，如checkExternalLoginKey这种类型的event就放在此处。其他和firstVisitEvents一样，废话不多讲。

3.1.5.store the actual request URI

执行完以上步骤保存本次请求的uri至requestAttribute，后面需要用到

3.1.6.Check securityAuth

判断用户是否需要登录（controller.xml中request-map—>security —>auth的值），如果值为true执行requestMapMap中checkLogin的event,执行过程中验证没有登陆则在session中记录下

_PREVIOUS_REQUEST_，_PREVIOUS_PARAM_MAP_URL_，

_PREVIOUS_PARAM_MAP_FORM_以便登陆后访问该地址，设置当前requestMap为checkLogin

3.1.7.处理目标Event

接下来一些判断，1、判断当初请求的request-map是无需登录的并且request-map的event不为空，2、继续判断request-map的type和

request-map的path不为空，如果满足1、2条件执行相应的event，我称之为目标Event。再把request event记录到ServerHit表中，记录ServerHit还是有可读的地方，比如ServerHit中的contentId，如果使用tenant模式，通过配置delegatorName（格式：

delegatorName#tenantId，如default#DEMO1），contentId的前面就会加上tenantId，从而知道是哪一个tenant访问的；其中ServerHit还有一些其他作用，最大最小执行时间，requestUrl以及referrerUrl等等（有些词语，解释成中文感觉不是那个味道，所以就直接用英文原词了），对于做数据分析是很有好处的，但是数据量大的时候ServerHit处还有一些Bug 需要修改。

3.1.8._REQ_ATTR_MAP_

还记得上面的callRedirect()吗，这里需要再次处理一下，首先取出

_REQ_ATTR_MAP_，判断是否曾做过callRedirect，如果有把从session 中移除，因为此时我们已经执行过Event，已经无需回头，没有任何意义了，同时把之前_REQ_ATTR_MAP_中的_ERROR_MESSAGE_LIST_、

_ERROR_MESSAGE_MAP_等存放到当前requestAttribute中，

3.1.9.if previous request exists,and a login just succeeded

这里判断了2个东西，_PREVIOUS_REQUEST_和_LOGIN_PASSED_，解释一下_PREVIOUS_REQUEST_来自于Session，记录上次访问的请求，_LOGIN_PASSED_来自于requestAttribute，如果为true，说明本次请求为登陆操作，并且登陆成功，那么需要做的是重定向到登陆前的页面即

_PREVIOUS_REQUEST_；

3.1.10._POST_CHAIN_VIEW_的判断

上面情况讲的是登陆后返回刚才请求的重定向，但是如果要指向到某个VIEW我们就需要用到postChainView，这个是根据请求地址分割出来的，比如我们看一下ecommerce主页上的登陆链接（https://XXXP地

址:8443/control/checkLogin/main）,完成event.checkLogin之后就会转向到view.main，不过此处不是做展现ChainView操作的，是确定event 执行后，successResponse类型的，如果类型是request则保存chainView 至requestAttribute；

3.1.11.保存SaveView信息至Session

判断是否符合Save条件（Do not save the view if the last view is the same as the current view and saveCurrentView is false，此举我不想翻译，太绕舌了，扛不住）;

3.1.12.doRequest

如果nextRequestResponse的类型为request，再来一把doRequest()；

3.1.13.针对nextRequestResponse.type执行相应代码处理

这一部分功能比较直白，即判断相应的类型，然后执行url跳转、从定向、renderView（渲染画面）等操作。渲染画面是一个非常大的部分也是Ofbiz中的经典模块，值得单独拿出来讲，很多人想做的页面静态化，就是用的这个实现的，等把这个请求控制篇写完了，就来写renderView。3.1.14.resp.flushBuffer()

渲染好了，一堆堆东西输出flushBuffer，就形成了我们看到的页面。

4.RequestHandler.java剩余扫尾工作

4.1.errorPage

再执行上面requestHandler.doRequest操作的时候，有N多种情况会出现异常，捕捉到异常获取默认错误页面—error.jsp

4.2.request.getRequestDispatcher(errorPage)

利用request.getRequestDispatcher(errorPage)方式，请求转发前后页面共享一个request，保证了errorMessageList，exception等还在

request中，错误页面能正常显示错误。