tomcat一启动,系统就会读取struts-config中的信息,此时,根据配置信息中的Action-mappings和form-beans,就会初始化装载请求action的配置信息和请求action对应的actionform的配置信息的两个map,这两个map的名字是actionconfigs和formbeanconfigs,系统就会把从配置信息读取到的数据,比如把所有action-mapping的配置信息放置到Actionconfigs,把所有actionform的配置信息放置到formbeanconfigs.
之后浏览器假如发出扩展名为.do的请求,当然所有这种请求都会被事先在web.xml中配置的struts1的核心控制器ActionServlet所捕获到。当然请求也会被纳入到核心控制器Actionservlet的管理。之后,核心控制器发现请求来了,就会首先调用processPath这个方法,自动分析请求地址,并对uri截取出除项目名外的子串。这个子串就是存储在actionconfigs中key的值。如果在接下来中,通过processMapping这个方法,找到了封装请求对应的配置信息的ActionMapping这个对象,就会通过processActionFrom这个方法去formbeanconfigs这个map中,依靠ActionMapping的name属性,拿到封装该Action对应的Actionform配置信息的formbeanconfig,如果formbeanconfig为null,则返回的也为null。这个时候,并不会马上返回一个ActionForm对象,会通过lookupActionForm这个方法去从scope中拿到actionform,如果actionform为空,则会通过反射机制创建ActionForm对象,并把它放置在scope对应的属性空间中。如果不为空,则从scope中直接返回该name对应的属性值。另外在不用框架以前,我们收集表单要么是手动收集,要么是通过Enumeration这个半自动的方式。然而,struts1在得到会创建ActionForm后,会通过processPopulate这个方法自动的将前台表单手机到我们事先在struts配置文件中action对应的ActionForm中。注意,很多时候我们都要通过处理将前台输入的表单中的字符串类型转化为我们需要的类型,这时候必然就需要写大量的java代码。但我们利用struts1中表单自动收集功能,就可以节省很多开发的时间和提高开发的效率,但有写类型是不能自动收集的,比如java .util.Date这个类型,就需要我们写相应的转化器转化成我们需要的类型。
我们刚刚谈论到表单自动收集,那表单自动收集之后,系统就会调用processActionCreate这个方法去创建请求对应的Action了。这时候注意主角登场了。在创建Action的时候,会有一个锁的机制,即单例+同步(那就是为什么struts1效率低的原因了,毕竟是在一到控制层创建Action就加了锁,那之后的业务层,持久层都得是单例加同步,不然会产生并发而造成的不安全的问题)。这个锁,注意是对装载Action的map进行加锁和同步。
之后,系统便会调用processActionperform这个方法去自动执行execute方法,这时候,我们可以在execute方法中,加入一些对业务层处理的操作,并把ActionForward返回给控制层ActionServlet。
最后,当然是处理客户端或服务端跳转了。此时系统就会调用processForwardConfig这个方法,如果ActionForward这个对象中的redirect属性为true,就是客户端跳转。如果ActionForward这个对象中的redirect属性为false,就是服务端跳转。