application context構造器通常使用字符串或字符串數組作為資源(比如組成context定義 的XML文件)的定位路徑。
當這樣的定位路徑?jīng)]有前綴時(shí)，指定的 Resource 類(lèi)型會(huì )通過(guò)這個(gè)路徑來(lái)被創(chuàng )建并被用來(lái)載入bean的定義，這都取決于你所指定的application context。例如，如果你使用下面的代碼來(lái)創(chuàng )建ClassPathXmlApplicationContext ：
ApplicationContext ctx = new ClassPathXmlApplicationContext("conf/appContext.xml");這些Bean的定義會(huì )通過(guò)classpath載入并使用ClassPathResource。而如果你象下面這么創(chuàng )建FileSystemXmlApplicationContext：
ApplicationContext ctx =new FileSystemClassPathXmlApplicationContext("conf/appContext.xml");這些Bean的定義會(huì )通過(guò)文件系統從相對于當前工作目錄中被載入。
請注意如果定位路徑使用classpath前綴或標準的URL前綴，那它就會(huì )覆蓋默認的Resource 類(lèi)型。因此下面的FileSystemXmlApplicationContext...
ApplicationContext ctx =new FileSystemXmlApplicationContext("classpath:conf/appContext.xml");...實(shí)際上會(huì )通過(guò)classpath載入其bean定義。然而它仍是個(gè)FileSystemXmlApplicationContext。如果后面它被當作ResourceLoader 來(lái)使用，那么任何沒(méi)有使用前綴的路徑依然會(huì )被當作一個(gè)文件系統路徑。
ClassPathXmlApplicationContext 提供了多種構造方法以便于初始化。但其核心是，如果我們僅僅提供由XML文件名組成的字符串數組(沒(méi)有完整路徑信息)， 而且還提供了Class；那么該ClassPathXmlApplicationContext就會(huì )從給定的類(lèi)中抽取路徑信息。
希望通過(guò)一個(gè)示例把這些闡述清楚。假設有這樣的目錄結構：
com/foo/services.xmldaos.xmlMessengerService.class
由 ‘services.xml‘ 和 ‘daos.xml‘ 中定義的bean組成的 ClassPathXmlApplicationContext 實(shí)例會(huì )象這樣地來(lái)實(shí)例化...
ApplicationContext ctx = new ClassPathXmlApplicationContext(new String[] {"services.xml", "daos.xml"}, MessengerService.class);欲了解 ClassPathXmlApplicationContext 多種構造方法的細節，請參考它的Javadocs。
Application context構造器中資源路徑的值可以是簡(jiǎn)單的路徑(就像上面的那樣)，即一對一映射到一個(gè)目標資源； 或者可以包含特殊的"classpath*:"前綴和Ant風(fēng)格的正則表達式(用Spring的 PathMatcher 工具來(lái)匹配)。 后面的二者都可以使用通配符。
該機制的一個(gè)用處就是做組件類(lèi)型的應用組裝。所有的組件都可以用通用的定位路徑“發(fā)布”context定義片斷， 這樣當使用相同的 classpath*: 前綴創(chuàng )建最終的application context時(shí)，所有的組件片斷都會(huì )被自動(dòng)裝入。
請注意，這個(gè)通配符只在application context構造器的資源路徑中 (或直接在類(lèi)的層次中使用 PathMatcher 工具時(shí))有效， 它會(huì )在構造時(shí)進(jìn)行解析。這與 Resource 類(lèi)型本身沒(méi)有關(guān)聯(lián)。因為同一時(shí)刻只能指向一個(gè)資源，所以不能使用 classpath*: 前綴來(lái)構造實(shí)際的Resource。
在包含Ant風(fēng)格的pattern時(shí)，例如：
/WEB-INF/*-context.xmlcom/mycompany/**/applicationContext.xmlfile:C:/some/path/*-context.xmlclasspath:com/mycompany/**/applicationContext.xml
解析器會(huì )進(jìn)行一個(gè)預先定義的復雜的過(guò)程去試圖解析通配符。 它根據路徑中最后一個(gè)非通配符片斷產(chǎn)生一個(gè)Resource并從中獲得一個(gè)URL。 如果這個(gè)URL不是一個(gè)"jar:" URL或特定容器的變量(例如WebLogic中的 "zip:"，WebSphere中的"wsjar"等等)， 那么可以從中獲得一個(gè)java.io.File， 并用它從文件系統中解析通配符。如果是一個(gè)jar URL，解析器可以從中取得一個(gè) java.net.JarURLConnection，或者手工解析該jar URL， 隨后遍歷jar文件以解析通配符。
如果給定的路徑已經(jīng)是一個(gè)文件URL(可以是顯式的或者是隱式的)， 由于基本的ResourceLoader是針對文件系統的，那么通配符一定能夠移植。
如果給定的路徑是一個(gè)classpath的位置，那么解析器必須通過(guò)一個(gè) Classloader.getResource() 調用獲得最后一個(gè) 非通配符路徑片斷的URL。因為這僅僅是一個(gè)路徑的節點(diǎn)(不是最終的文件)， 所以它并未確切定義(在 ClassLoader Javadocs里) 此處究竟會(huì )返回什么類(lèi)型的URL。一般情況下，當classpath資源解析為一個(gè)文件系統位置時(shí)， 返回一個(gè)代表目錄的 java.io.File；當解析為jar位置時(shí)， 返回某類(lèi)jar URL。當然，這個(gè)操作涉及到可移植性。
如果從最后一個(gè)非通配符片斷中獲得一個(gè)jar URL，那么解析器一定能從中取得一個(gè) java.net.JarURLConnection，或者手動(dòng)解析jar URL以遍歷jar文件， 從而解析通配符。這一操作在大多數環(huán)境中能正常工作，不過(guò)也有例外， 因此我們強烈建議特定環(huán)境中的jar資源通配符解析應在正式使用前要經(jīng)過(guò)徹底測試。
當構造基于XML的application context時(shí)，路徑字符串可能使用特殊的 classpath*: 前綴：
ApplicationContext ctx =new ClassPathXmlApplicationContext("classpath*:conf/appContext.xml");此前綴表示所有與給定名稱(chēng)匹配的classpath資源都應該被獲取(其中，這經(jīng)常會(huì )在調用 ClassLoader.getResources(...)) 時(shí)發(fā)生)，并接著(zhù)將那些資源全并成最終的application context定義。
 | Classpath*: 的可移植性 |
|---|---|
| 帶通配符的classpath依賴(lài)于底層classloader的 getResources() 方法。 現在大多數的應用服務(wù)器提供自己的classloader實(shí)現，它們在處理jar文件時(shí)的行為也許會(huì )有所不同。 要測試 classpath*: 是否有效，可以簡(jiǎn)單地用classloader從classpath中的jar文件里加載一個(gè)文件： getClass().getClassLoader().getResources("<someFileInsideTheJar>")。 針對兩個(gè)不同位置但有相同名字的文件來(lái)運行測試。如果結果不對，那么就查看一下應用服務(wù)器的文檔， 特別是那些可能影響classloader行為的設置。 | |
"classpath*:"前綴也能在位置路徑的其他部分結合PathMatcher pattern一起使用，例如"classpath*:META-INF/*-beans.xml"。在這里， 解析策略很簡(jiǎn)單：對最后一個(gè)非通配符路徑片斷使用一個(gè)ClassLoader.getResources()調用， 從類(lèi)加載層次中獲得所有滿(mǎn)足的資源，隨后針對子路徑的通配符， 將同一個(gè)PathMatcher解析策略運用于每個(gè)資源之上。
請注意如果目標文件不是在文件系統中，那么"classpath*:" 在結合Ant風(fēng)格的pattern時(shí)必須在pattern開(kāi)始前包含至少一個(gè)根路徑才能保證其正確性。 像"classpath*:*.xml"這樣的pattern不能從jar文件的根目錄取得文件， 而只能從這個(gè)根目錄的子目錄中獲得文件。這個(gè)問(wèn)題源自JDK中 ClassLoader.getResources() 方法的一個(gè)局限性，即該方法在傳入空String(指示要搜索的潛在根目錄)時(shí)只返回文件系統位置。
如果搜索的根包在多個(gè)類(lèi)路徑位置上，帶"classpath:"的Ant風(fēng)格pattern 資源不能保證一定可以找到匹配的資源。這是因為像
com/mycompany/package1/service-context.xml
這樣的資源只可能在一個(gè)位置，但如果要解析的是如下路徑
classpath:com/mycompany/**/service-context.xml
解析器會(huì )排除getResource("com/mycompany");返回的(第一個(gè))URL。 如果這個(gè)基礎包節點(diǎn)存在于多個(gè)classloader位置，最終要找的資源未必會(huì )被發(fā)現。 因此在這種情況中最好在這個(gè)Ant風(fēng)格的pattern中使用"classpath*:"， 這樣就會(huì )搜索包含根包在內所有類(lèi)路徑。
一個(gè)并沒(méi)有與 FileSystemApplicationContext 綁定的 FileSystemResource(也就是說(shuō)FileSystemApplicationContext 并不是真正的ResourceLoader)，會(huì )象你期望的那樣分辨絕對和相對路徑。 相對路徑是相對于當前的工作目錄，而絕對路徑是相對與文件系統的根目錄。
為了向前兼容的目的，當 FileSystemApplicationContext 是個(gè) ResourceLoader 時(shí)它會(huì )發(fā)生變化。FileSystemApplicationContext 會(huì )簡(jiǎn)單地讓所有綁定的 FileSystemResource 實(shí)例把絕對路徑都當成相對路徑， 而不管它們是否以反斜杠開(kāi)頭。也就是說(shuō)，下面的含義是相同的：
ApplicationContext ctx =new FileSystemClassPathXmlApplicationContext("conf/context.xml");ApplicationContext ctx =new FileSystemClassPathXmlApplicationContext("/conf/context.xml");下面的也一樣：(雖然把它們區分開(kāi)來(lái)也很有意義，但其中的一個(gè)是相對路徑而另一個(gè)則是絕對路徑)。
FileSystemXmlApplicationContext ctx = ...;ctx.getResource("some/resource/path/myTemplate.txt");FileSystemXmlApplicationContext ctx = ...;ctx.getResource("/some/resource/path/myTemplate.txt");實(shí)際上如果的確需要使用絕對路徑，那你最好就不要使用 FileSystemResource 或 FileSystemXmlApplicationContext來(lái)確定絕對路徑。我們可以通過(guò)使用 file: URL前綴來(lái)強制使用UrlResource。
// actual context type doesn‘t matter, the Resource will always be UrlResourcectx.getResource("file:/some/resource/path/myTemplate.txt");// force this FileSystemXmlApplicationContext to load it‘s definition via a UrlResourceApplicationContext ctx =new FileSystemXmlApplicationContext("file:/conf/context.xml");聯(lián)系客服
