ApplicationContext研究

ApplicationContext是Spring的核心,Context我们通常解释为上下文环境,我想用“容器”来表述它更容易理解一些,ApplicationContext则是“应用的容器”了:P,Spring把Bean放在这个容器中,在需要的时候,用getBean方法取出,虽然我没有看过这一部分的源代码,但我想它应该是一个类似Map的结构。
在Web应用中,我们会用到WebApplicationContext,WebApplicationContext继承自ApplicationContext,先让我们看看在Web应用中,怎么初始化WebApplicationContext,在web.xml中定义:
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>/WEB-INF/applicationContext.xml</param-value>
</context-param>

<listener>
<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>

<!– OR USE THE CONTEXTLOADERSERVLET INSTEAD OF THE LISTENER
<servlet>
<servlet-name>context</servlet-name>
<servlet-class>org.springframework.web.context.ContextLoaderServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
–>

可以看出,有两种方法,一个是用ContextLoaderListener这个Listerner,另一个是ContextLoaderServlet这个Servlet,这两个方法都是在web应用启动的时候来初始化WebApplicationContext,我个人认为Listerner要比Servlet更好一些,因为Listerner监听应用的启动和结束,而Servlet得启动要稍微延迟一些,如果在这时要做一些业务的操作,启动的前后顺序是有影响的。

那么在ContextLoaderListener和ContextLoaderServlet中到底做了什么呢?
以ContextLoaderListener为例,我们可以看到
public void contextInitialized(ServletContextEvent event) {
this.contextLoader = createContextLoader();
this.contextLoader.initWebApplicationContext(event.getServletContext());
}
protected ContextLoader createContextLoader() {
return new ContextLoader();
}
ContextLoader是一个工具类,用来初始化WebApplicationContext,其主要方法就是initWebApplicationContext,我们继续追踪initWebApplicationContext这个方法(具体代码我不贴出,大家可以看Spring中的源码),我们发现,原来ContextLoader是把WebApplicationContext(XmlWebApplicationContext是默认实现类)放在了ServletContext中,ServletContext也是一个“容器”,也是一个类似Map的结构,而WebApplicationContext在ServletContext中的KEY就是WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE,我们如果要使用WebApplicationContext则需要从ServletContext取出,Spring提供了一个WebApplicationContextUtils类,可以方便的取出WebApplicationContext,只要把ServletContext传入就可以了。

上面我们介绍了WebApplicationContext在Servlet容器中初始化的原理,一般的Web应用就可以轻松的使用了,但是,随着Struts的广泛应用,把Struts和Spring整个起来,是一个需要面对的问题,Spring本身也提供了Struts的相关类,主要使用的有org.springframework.web.struts.ActionSupport,我们只要把自己的Action继承自ActionSupport,就是可以调用ActionSupport中getWebApplicationContext()的方法取出WebApplicationContext,但这样一来在Action中,需要取得业务逻辑的地方都要getBean,看上去不够简洁,所以Spring又提供了另一个方法,用org.springframework.web.struts.ContextLoaderPlugIn,这是一个Struts的Plug,在Struts启动时加载,对于Action,可以像管理Bean一样来管理,在struts-config.xml中Action的配置变成类似下面的样子
<action attribute=”aForm” name=”aForm” path=”/aAction” scope=”request”  type=”org.springframework.web.struts.DelegatingActionProxy”>
<forward name=”forward” path=”forward.jsp” />
</action>
注意type变成了org.springframework.web.struts.DelegatingActionProxy,之后我们需要建立action-servlet.xml这样的文件,action-servlet.xml符合Spring的spring-beans.dtd标准,在里面定义类似下面的
<bean name=”/aAction” class=”com.web.action.Aaction” singleton=”false”>
<property name=”businessService”>
<ref bean=”businessService”/>
</property>
</bean>

com.web.action.Aaction是Action的实现类,businessService是需要的业务逻辑,Spring会把businessService注入到Action中,在Action中只要写businessService的get和set方法就可以了,还有一点,action的bean是singleton=”false”,即每次新建一个实例,这也解决了Struts中Action的线程同步问题,具体过程是当用户做“/aAction”的HTTP请求(当然应该是“/aAction.do”),Struts会找到这个Action的对应类org.springframework.web.struts.DelegatingActionProxy,DelegatingActionProxy是个代理类,它会去找action-servlet.xml文件中“/aAction”对应的真正实现类,然后把它实例化,同时把需要的业务对象注入,然后执行Action的execute方法。

使用了ContextLoaderPlugIn,在struts-config.xml中变成类似这样配置
<plug-in className=”org.springframework.web.struts.ContextLoaderPlugIn”>
<set-property property=”contextConfigLocation” value=”/WEB-INF/applicationContext.xml,/WEB-INF/action-servlet.xml” />
</plug-in>
而在web.xml中不再需要ContextLoaderListener或是ContextLoaderServlet。

说到这里不知道大家会不会有这样的问题,如果使用ContextLoaderPlugIn,如果我们有些程序是脱离Struts的Action环境,我们怎么处理,比如我们要自定义标记库,在标记库中,我们需要调用Spring管理的业务层逻辑对象,这时候我们就很麻烦,因为只有在action中动态注入业务逻辑,其他我们似乎不能取得Spring的WebApplicationContext。

别急,我们还是来看一下ContextLoaderPlugIn的源码(源码不再贴出),我们可以发现,原来ContextLoaderPlugIn仍然是把WebApplicationContext放在ServletContext中,只是这个KEY不太一样了,这个KEY值为ContextLoaderPlugIn.SERVLET_CONTEXT_PREFIX+ModuleConfig.getPrefix()(具体请查看源代码),这下好了,我们知道了WebApplicationContext放在哪里,只要我们在Web应用中能够取到ServletContext也就能取到WebApplicationContext了:)

再说“i”

想了想,我博客的标题就用I@laoer.com吧,为什么用i,这是有历史原因的,呵呵:)

当年我在网易工作,丁磊在网易通行证的代号就是i,他的电子邮件也就是i@163.com,他会经常在网易的各个产品里溜达,如果我们发现了在线用户里有“i”,就知道丁磊在看,这时一定不能出什么纰漏,要不然,哈哈…

如今我也效仿他老人家一下,I@laoer.com

Struts2小结

天乙社区8.0(http://www.laoer.com)已经完全用Struts2实现,在使用Struts的过程中也遇到了一些问题,现在总结一下。

1、在web.xml中EncodingFilter的位置应该在Struts2的FilterDispatcher之前,道理很简单,要先调整字符集,再进入Action。

2、如果使用Urlrewrite,要指定filter-mapping的dispatcher方式,如下
<filter-mapping>
<filter-name>Struts2</filter-name>
<url-pattern>/*</url-pattern>
<dispatcher>REQUEST</dispatcher>
<dispatcher>FORWARD</dispatcher>
</filter-mapping>

3、在做上传文件的时候,要在web.xml中增加ActionContextCleanUp这个filter,如果不增加,会发生第一次上传取不到文件的情况
<filter>
<filter-name>struts-cleanup</filter-name>
<filter-class>org.apache.struts2.dispatcher.ActionContextCleanUp</filter-class>
</filter>
<filter-mapping>
<filter-name>struts-cleanup</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
按照Struts2的API,filter的顺序是
struts-cleanup filter
SiteMesh filter
FilterDispatcher

4、在Apache+Resin的情况下,要在WEB-INF下增加resin-web.xml,该文件只针对Resin有效,作用是指定后缀与 Resin的Servlet引擎匹配,要不然从Apache转发过去的请求到Resin后会出现404的情况,resin-web.xml举例如下:
<web-app xmlns=”http://caucho.com/ns/resin”>
<servlet-mapping url-pattern=’*.bbscs’ servlet-name=’plugin_match’/>
</web-app>

5、在使用<s:url/>标签的时候,会出现将get或post数值带入url参数的情况,如果不需要这些参数,可以在struts.properties文件中设置
struts.url.includeParams=none
或是在<s:url/>标记中将includeParams属性设为none
另外还有两个值
all,是把get和post中的参数加入到url参数中
get,是只把get中的参数加入到url参数中

6、与webwork基本相同,Struts2提供了几种ui.theme,有xhtml、css_xhtml、simple等等,在 struts.properties中可以设置使用何种theme,这一点很关键,不同的theme,struts的tag会生成不同的html代码,而且在某些情况下这些theme不能满足页面要求,则需要自己进行扩展了,这些theme都是由freemarker写的,仿照这写就可以。

7、单个checkbox的标记库好像只能返回boolean的值,如果在数据库中设计为int型,则需要做一些转换,这一点我觉得不如Struts1.x的方便。

8、总体来说Struts2的标记库使用上比Struts1.x的方便,页面整体也比较简洁,Struts2采用stack的方式存取数据,与Struts1相比各有千秋吧。

Struts2主要延续自webwork,以前使用webwork的朋友转过来并不困难,Struts2的几个核心的部分,比如拦截器、Result Configuration、OGNL stack等等还是需要仔细的体会,深入了解,才能做出优秀的系统。

(这篇文章在JavaEye上发表过)

Tomcat AJP Connector参数调整

最近公司的一个面向C端客户的网站应用频繁的Down掉,昨天早上重起Tomcat后,快到下午下班时有不响应了,我们采用的是Apache+Tomcat,Apache和Tomcat之间采用的是AJP,在应用Down机的时候发现直接访问Tomcat的端口没有问题,而Apache的性能应该没有问题,其参数我也调整过,而且我们的访问量并不算很大,服务器的Idel也一直处于空闲状态,由此判断,估计是Apache到Tomcat的连接出了什么问题,晚上回家我查了查Tomcat的文档,找到AJP这部分配置(http://tomcat.apache.org/tomcat-5.5-doc/config/ajp.html),里面Standard Implementation部分有maxThreads、maxSpareThreads、minSpareThreads这几个参数,我想应该是AJP Connector原有的参数设置的太小或是不合理造成的,相应修改这几个参数,重起Tomcat看看情况如何。