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了:)
Spring是一個很強大的框架,希望大家在使用過程中不斷的深入,了解其更多的特性,我在這
里拋磚引玉,有什么不對的地方,請大家指出。
所以可以直接在ServletContext取出WebApplicationContext 對象:
WebApplicationContext webApplicationContext = (WebApplicationContext) servletContext.getAttribute(WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE);
事實上WebApplicationContextUtils.getWebApplicationContext方法就是使用上面的代碼實現的,建議使用上面上面的靜態方法
看了許多關于Comparator接口的實現和解決方法,感覺大多都不是太符合jdk的原意。
Comparator接口是對Comparable接口的另一種補充。她使數據和算法分離。(在比較的時候) Comparable接口是數據和算法綁定,這本身并沒有好和壞的分別,只是不同的角度去思考同一問題。因此從分離的角度出發,Comparator接口對比較的兩個對象要求的類型更加的隨意,而java 反射機制正是對這一需求的一個合理解決方案。我們在得到比較的兩個對象時,比較大小,其實就是比較他們某個屬性的大小,決定返回的是-1,0,1中的一個。而屬性的結果是通過方法返回的,所以我們可以通過反射得到他的方法集合,循環方法去得到希望的屬性。具體的希望屬性,需要用戶提供比如年齡,工資,或者其他屬性。這樣就做到了比較并且分離算法和數據。
反射的必要條件: object1,object2,field
代碼:public int compare( Object o1, Object o2 ) {
Object result1 = getValue( o1 , field)
Object result2 = getValue( o2 , field);
//
if( result1 instanceof Date && result2 instanceof Date )
if(orderFlag.equals("asc"))
return ((Date)result1).compareTo((Date)result2);
else
{
if(((Date)result1).compareTo((Date)result2) < 0 )
return 1;
if(((Date)result1).compareTo((Date)result2) > 0)
return -1;
}
//
if( result1 instanceof String && result2 instanceof String ) {
if( result1.toString().equals( result2.toString() ) )
return 0;
else
return -1;
}
//其他類型的比較!!!
return 0
}
private Object getValue( Object obj , String fileName ) {
Method[] methods = obj.getClass().getMethods();
Object value = null;
for(Method method: methods){
String name = method.getName();
if(name .equals("get") && name .toLowerCase().indexOf(fileName )){
try{
value = method.invok(obj ,new Object[]{});
}catch(Exception e){e.printStackTrace();}
break;
}
}
return value;
}