文章目錄

• • • 1 介紹
    • 2 Resource 接口
    • • resource接口提供哪些功能？
    • 3 spring為我們提供了哪些內(nèi)置的Resource實(shí)現(xiàn)
    • • 3.1 URLResource
      • 3.2 ClassPathResource
      • 3.3 FileSystemResource
      • 3.4 InputStreamResource
      • 3.5 ByteArrayResource
    • 4 ResourceLoader 資源加載
    • 5 ResourceLoaderAware
    • 6 Resources as Dependencies
    • 7 Application Contexts and Resource Paths
    • • 7.1 Constructing Application Contexts
      • 7.2Wildcards in Application Context Constructor Resource Paths
      • • **Ant-style Patterns**
        • 可移植性
        • The `classpath*:` Prefix
      • FileSystemResource Caveats

spring如何處理資源（Resource），我們?nèi)绾卧趕pring中和資源（Resource）工作呢？

1 介紹

java.net.URL

可以處理各種復(fù)雜的URL（統(tǒng)一資源定位），缺點(diǎn)是對(duì)于所有訪問(wèn)底層資源的能力還不夠

例如還沒(méi)有一種URL的實(shí)現(xiàn)可以訪問(wèn)需要從類(lèi)路徑或相對(duì)于ServletContext獲得的資源雖然可以為專(zhuān)門(mén)的URL前綴注冊(cè)新的處理程序(類(lèi)似于現(xiàn)有的用于前綴的處理程序，如http:)，但這通常非常復(fù)雜。而且URL接口仍然缺少一些需要的功能，比如檢查被指向的資源是否存在的方法

思考：Resource接口是用來(lái)解決什么問(wèn)題的？即URL接口的這些不足。

2 Resource 接口

比URL接口更強(qiáng)，用于抽象對(duì)底層資源的訪問(wèn)。

對(duì)比URL接口，Resource接口有何不同，URL表示一個(gè)統(tǒng)一的資源定位符，一個(gè)指向萬(wàn)維網(wǎng)上“資源”的指針，相較于Resource更加側(cè)重于web資源，且無(wú)法判斷資源是否存在

相較于URL Resource接口實(shí)現(xiàn)資源的抽象，可以檢查資源是否存在。

URL protocol，host，port，authority，file，ref

resource接口提供哪些功能？

判斷提供資源其他

isReadable	URL	createRelative
isOpen	URI	contentLength
isFile	File	lastModified
exists	InputStream	ReadableByteChannel

通過(guò)字符串路徑上的特殊前綴，指定必須創(chuàng)建和使用特定的資源實(shí)現(xiàn)，例如：ftp，http，file

資源抽象不能代替功能。在可能的地方進(jìn)行包裝。例如，UrlResource包裝一個(gè)URL并使用包裝后的URL來(lái)完成它的工作。

Resource接口的子類(lèi)有以下這些

3 spring為我們提供了哪些內(nèi)置的Resource實(shí)現(xiàn)

• UrlResource
• ClassPathResource
• FileSystemResource
• ServletContextResource
• InputStreamResource
• ByteArrayResource

3.1 URLResource

包裝了URL接口，可以用來(lái)訪問(wèn)File，Http，ftp等其他對(duì)象，UrlResource是由Java代碼顯式地使用UrlResource構(gòu)造函數(shù)創(chuàng)建的，但通常在調(diào)用API方法時(shí)隱式地創(chuàng)建，該方法接受一個(gè)表示路徑的字符串參數(shù)。對(duì)于后一種情況，JavaBeans PropertyEditor最終決定創(chuàng)建哪種類(lèi)型的資源。路徑字符串包含眾所周知的(也就是)前綴(例如classpath:)，它為該前綴創(chuàng)建一個(gè)適當(dāng)?shù)膶?zhuān)門(mén)化資源。但是，如果它不識(shí)別前綴，則假定該字符串是標(biāo)準(zhǔn)URL字符串，并創(chuàng)建一個(gè)UrlResource。

PropertyEditor

3.2 ClassPathResource

從類(lèi)路徑下獲取（classpath），隱式創(chuàng)建當(dāng)字符串路徑上的特殊前綴classpath:，PropertyEditor將創(chuàng)建一個(gè)ClassPathResource實(shí)例

3.3 FileSystemResource

File和Path 的Resource實(shí)現(xiàn)，支持解析File和URL

3.4 InputStreamResource

InputStream的Resource實(shí)現(xiàn)，只有在沒(méi)有特定的資源實(shí)現(xiàn)可用時(shí)，才應(yīng)該使用它。特別是，盡可能選擇ByteArrayResource或任何基于文件的資源實(shí)現(xiàn)。如果您需要將資源描述符保存在某個(gè)地方，或者需要多次讀取流，請(qǐng)不要使用它

3.5 ByteArrayResource

這是一個(gè)給定字節(jié)數(shù)組的資源實(shí)現(xiàn)。它為給定的字節(jié)數(shù)組創(chuàng)建一個(gè)ByteArrayInputStream。它對(duì)于從任何給定的字節(jié)數(shù)組加載內(nèi)容都很有用，而不必求助于一次性使用的InputStreamResource

classpath：ClassPathResource

File，Path	FileSystemResource
InputStreamResource	盡量不用
ByteArrayResource	byte array --ByteArrayInputStream

4 ResourceLoader 資源加載

由可以返回(即加載)資源實(shí)例的對(duì)象來(lái)實(shí)現(xiàn)的。

public interface ResourceLoader {Resource getResource(String location); }

applicationcontext于resouce的關(guān)系，如果沒(méi)有指定特殊前綴，將獲得適合于特定應(yīng)用程序上下文的資源類(lèi)型

上下文類(lèi)型返回資源類(lèi)型

ClassPathXmlApplicationContext	ClassPathResource
FileSystemXmlApplicationContext	FileSystemResource
WebApplicationContext	ServletContextResource

用例

Resource template = ctx.getResource("classpath:some/resource/path/myTemplate.txt"); Resource template = ctx.getResource("file:///some/resource/path/myTemplate.txt"); Resource template = ctx.getResource("https://myhost.com/resource/path/myTemplate.txt");

資源和字符串路徑的關(guān)系

PrefixExampleExplanation

classpath:	classpath:com/myapp/config.xml	Loaded from the classpath.
file:	file:///data/config.xml	Loaded as a URL from the filesystem. See also FileSystemResource Caveats.
http:	https://myserver/logo.png	Loaded as a URL.
(none)	/data/config.xml	Depends on the underlying ApplicationContext.

5 ResourceLoaderAware

當(dāng)類(lèi)實(shí)現(xiàn)ResourceLoaderAware并部署到應(yīng)用程序上下文中（作為Spring托管的bean）時(shí)，該類(lèi)被應(yīng)用程序上下文識(shí)別為ResourceLoaderAware。 然后，應(yīng)用程序上下文調(diào)用setResourceLoader（ResourceLoader），將自身作為參數(shù)提供（請(qǐng)記住，Spring中的所有應(yīng)用程序上下文均實(shí)現(xiàn)ResourceLoader接口）

在應(yīng)用程序組件中，您還可以依賴(lài)自動(dòng)裝配ResourceLoader來(lái)實(shí)現(xiàn)ResourceLoaderAware接口。 “傳統(tǒng)”構(gòu)造函數(shù)和byType自動(dòng)裝配模式（如“自動(dòng)裝配協(xié)作器”中所述）能夠分別為構(gòu)造函數(shù)參數(shù)或setter方法參數(shù)提供ResourceLoader。 為了獲得更大的靈活性（包括自動(dòng)裝配字段和多個(gè)參數(shù)方法的能力），請(qǐng)考慮使用基于注釋的自動(dòng)裝配功能。 在這種情況下，只要有問(wèn)題的字段，構(gòu)造函數(shù)或方法帶有@Autowired批注，ResourceLoader就會(huì)自動(dòng)連接到需要ResourceLoader類(lèi)型的字段，構(gòu)造函數(shù)參數(shù)或方法參數(shù)中。 有關(guān)更多信息，請(qǐng)參見(jiàn)使用@Autowired。

即ResourceLoaderAware 接口可以獲得實(shí)現(xiàn)了ResourceLoader的類(lèi)，好像還與自動(dòng)裝配存在著某種聯(lián)系。自動(dòng)裝配的核心是BeanpostProcessor，其可以在bean實(shí)例化前后對(duì)bean進(jìn)行一系列操作。

6 Resources as Dependencies

資源可以作為依賴(lài)

<bean id="myBean" class="..."><property name="template" value="some/resource/path/myTemplate.txt"/><property name="template" value="file:///some/resource/path/myTemplate.txt"/><property name="template" value="classpath:some/resource/path/myTemplate.txt"> </bean>

7 Application Contexts and Resource Paths

應(yīng)用上下文和資源路徑

7.1 Constructing Application Contexts

創(chuàng)建應(yīng)用上下文需要依賴(lài)資源路徑，應(yīng)用上下文從資源路徑中加載bean的定義，當(dāng)這樣的位置路徑?jīng)]有前綴時(shí)，從該路徑構(gòu)建并用于加載bean定義的特定資源類(lèi)型依賴(lài)于特定的應(yīng)用程序上下文，并且適合于特定的應(yīng)用程序上下文。

應(yīng)用上下文類(lèi)型資源路徑

new ClassPathXmlApplicationContext(“conf/appContext.xml”);	classpath
new FileSystemXmlApplicationContext(“conf/appContext.xml”);	file system
new FileSystemXmlApplicationContext(“classpath:conf/appContext.xml”);	classpath

使用FileSystemXmlApplicationContext從類(lèi)路徑加載bean定義。但是，它仍然是FileSystemXmlApplicationContext。如果它隨后被用作ResourceLoader，那么任何不帶前綴的路徑仍然被視為文件系統(tǒng)路徑。

com/foo/services.xmldaos.xmlMessengerService.class

以下示例顯示如何實(shí)例化由在名為service.xml和daos.xml（位于類(lèi)路徑中）的文件中定義的bean組成的ClassPathXmlApplicationContext實(shí)例。

ApplicationContext ctx = new ClassPathXmlApplicationContext(new String[] {"services.xml", "daos.xml"}, MessengerService.class);

感覺(jué)對(duì)于classpath 和包名之間的關(guān)系還是有點(diǎn)不清晰

7.2Wildcards in Application Context Constructor Resource Paths

應(yīng)用程序上下文構(gòu)造器資源路徑中的通配符

此機(jī)制的一個(gè)用途是，當(dāng)您需要進(jìn)行組件樣式的應(yīng)用程序組裝時(shí)。所有組件都可以將上下文定義片段“發(fā)布”到一個(gè)已知的位置路徑，并且，當(dāng)使用以classpath*:作為前綴的相同路徑創(chuàng)建最終的應(yīng)用程序上下文時(shí)，所有組件片段都會(huì)自動(dòng)被獲取。注意，這種通配符是特定于在應(yīng)用程序上下文構(gòu)造函數(shù)中使用資源路徑的，在構(gòu)建應(yīng)用時(shí)進(jìn)行解析。

與資源類(lèi)型本身無(wú)關(guān)。您不能使用classpath*:前綴來(lái)構(gòu)造實(shí)際的資源，因?yàn)橐粋€(gè)資源一次只能指向一個(gè)資源。

多模塊應(yīng)用中的使用classpath*

Ant-style Patterns

/WEB-INF/*-context.xml com/mycompany/**/applicationContext.xml file:C:/some/path/*-context.xml classpath:com/mycompany/**/applicationContext.xml

When the path location contains an Ant-style pattern, the resolver follows a more complex procedure to try to resolve the wildcard. It produces a Resource for the path up to the last non-wildcard segment and obtains a URL from it. If this URL is not a jar: URL or container-specific variant (such as zip: in WebLogic, wsjar in WebSphere, and so on), a java.io.File is obtained from it and used to resolve the wildcard by traversing the filesystem. In the case of a jar URL, the resolver either gets a java.net.JarURLConnection from it or manually parses the jar URL and then traverses the contents of the jar file to resolve the wildcards.

如果有路徑機(jī)制含有 Ant-style pattern，解析器會(huì)使用更加復(fù)雜的程序嘗試解析通配符。

匹配規(guī)則

The mapping matches URLs using the following rules:

• ? matches one character
• ***** matches zero or more characters
• ** matches zero or more ‘directories’ in a path
• {spring:[a-z]+} matches the regexp [a-z]+ as a path variable named “spring”

Some examples:

• com/t?st.jsp - matches com/test.jsp but also com/tast.jsp or com/txst.jsp
• com/*.jsp - matches all .jsp files in the com directory
• com/**/test.jsp - matches all test.jsp files underneath the com path
• org/springframework/**/*.jsp - matches all .jsp files underneath the org/springframework path
• org/**/servlet/bla.jsp - matches org/springframework/servlet/bla.jsp but also org/springframework/testing/servlet/bla.jsp and org/servlet/bla.jsp
• com/{filename:\w+}.jsp will match com/test.jsp and assign the value test to the filename variable

可移植性

如果指定的路徑已經(jīng)是一個(gè)文件URL（由于基本ResourceLoader是一個(gè)文件系統(tǒng)，所以它是隱式的，或者是顯式的），則保證通配符可以完全可移植的方式工作。

如果指定的路徑是類(lèi)路徑位置，則解析器必須通過(guò)調(diào)用Classloader.getResource（）獲得最后的非通配符路徑段URL。 由于這只是路徑的一個(gè)節(jié)點(diǎn)（而不是末尾的文件），因此實(shí)際上（在ClassLoader javadoc中）未定義確切返回的是哪種URL。 實(shí)際上，它始終是一個(gè)java.io.File，代表目錄（類(lèi)路徑資源解析為文件系統(tǒng)位置）或某個(gè)jar URL（類(lèi)路徑資源解析為jar位置）。 盡管如此，此操作仍存在可移植性問(wèn)題。

如果為最后一個(gè)非通配符段獲取了jar URL，則解析程序必須能夠從中獲取java.net.JarURLConnection或手動(dòng)解析jar URL，以便能夠遍歷jar的內(nèi)容并解析通配符 。 這在大多數(shù)環(huán)境中確實(shí)有效，但在其他環(huán)境中則無(wú)效，因此我們強(qiáng)烈建議您在依賴(lài)特定環(huán)境之前，對(duì)來(lái)自jars的資源的通配符解析進(jìn)行徹底測(cè)試

移植性于路徑關(guān)系

路徑樣式移植性是否有影響

file URL	無(wú)影響
classpath location	可能有一些
jar URL	徹底測(cè)試

The classpath*: Prefix

在構(gòu)造基于xml的應(yīng)用程序上下文時(shí)，位置字符串可以使用特殊的classpath*:前綴，如下面的示例所示

ApplicationContext ctx =new ClassPathXmlApplicationContext("classpath*:conf/appContext.xml");

這個(gè)特殊的前綴指定必須獲取所有與給定名稱(chēng)匹配的類(lèi)路徑資源(在內(nèi)部，這實(shí)際上是通過(guò)調(diào)用ClassLoader來(lái)實(shí)現(xiàn)的。然后合并形成最終的應(yīng)用程序上下文定義

通配符類(lèi)路徑依賴(lài)于基礎(chǔ)類(lèi)加載器的getResources（）方法。 由于當(dāng)今大多數(shù)應(yīng)用程序服務(wù)器都提供自己的類(lèi)加載器實(shí)現(xiàn)，因此行為可能有所不同，尤其是在處理jar文件時(shí)。 檢查classpath *是否可行的簡(jiǎn)單測(cè)試是使用classloader從classpath的jar中加載文件：getClass（）。getClassLoader（）。getResources（“ ”）。 嘗試對(duì)具有相同名稱(chēng)但位于兩個(gè)不同位置的文件進(jìn)行此測(cè)試。 如果返回了不合適的結(jié)果，請(qǐng)檢查應(yīng)用程序服務(wù)器文檔中可能影響類(lèi)加載器行為的設(shè)置。

還可以在其余位置路徑中將classpath *：前綴與PathMatcher模式結(jié)合使用（例如，classpath *：META-INF / *-beans.xml）。 在這種情況下，解析策略非常簡(jiǎn)單：在最后一個(gè)非通配符路徑段上使用ClassLoader.getResources（）調(diào)用，以獲取類(lèi)加載器層次結(jié)構(gòu)中的所有匹配資源，然后從每個(gè)資源獲取相同的PathMatcher解析 前面描述的策略用于通配符子路徑。

注意classpath*:，當(dāng)與 Ant-style模式結(jié)合使用時(shí)，除非實(shí)際的目標(biāo)文件駐留在文件系統(tǒng)中，否則classpath*:只能在模式啟動(dòng)之前可靠地與至少一個(gè)根目錄一起工作。這意味著，類(lèi)似classpath*😗.xml這樣的模式可能不會(huì)從jar文件的根目錄檢索文件，而是只從擴(kuò)展目錄的根目錄檢索文件。

帶有類(lèi)路徑的ant樣式模式:如果要搜索的根包在多個(gè)類(lèi)路徑位置可用，則不能保證資源能夠找到匹配的資源。考慮下面的資源位置示例

com/mycompany/package1/service-context.xml

現(xiàn)在考慮某人可能用來(lái)嘗試找到該文件的Ant樣式路徑

classpath:com/mycompany/**/service-context.xml

這樣的資源可能只在一個(gè)位置，但是當(dāng)使用諸如上一示例的路徑嘗試對(duì)其進(jìn)行解析時(shí)，解析器將根據(jù)getResource（“ com / mycompany”）返回的（第一個(gè)）URL進(jìn)行工作。如果此基本包節(jié)點(diǎn)存在于多個(gè)類(lèi)加載器位置，則實(shí)際的最終資源可能不存在。因此，在這種情況下，您應(yīng)該使用與ant樣式相同的classpath*:，它搜索包含根包的所有類(lèi)路徑位置。

FileSystemResource Caveats

文件系統(tǒng)資源警告

未附加到FileSystemApplicationContext的FileSystemResource（即，當(dāng)FileSystemApplicationContext不是實(shí)際的ResourceLoader時(shí)）將按您期望的那樣處理絕對(duì)路徑和相對(duì)路徑。 相對(duì)路徑是相對(duì)于當(dāng)前工作目錄的，而絕對(duì)路徑是相對(duì)于文件系統(tǒng)的根的。

但是，出于向后兼容性(歷史原因)的原因，當(dāng)FileSystemApplicationContext是ResourceLoader時(shí)，這種情況會(huì)發(fā)生變化。FileSystemApplicationContext強(qiáng)制所有附加的FileSystemResource實(shí)例將所有位置路徑視為相對(duì)路徑，不管它們是否以正斜杠開(kāi)頭。在實(shí)踐中，這意味著下面的例子是等價(jià)的

ApplicationContext ctx = **new** FileSystemXmlApplicationContext("conf/context.xml"); ApplicationContext ctx =new FileSystemXmlApplicationContext("/conf/context.xml");

下面的例子也是等價(jià)的(盡管它們不同是有意義的，因?yàn)橐环N情況是相對(duì)的，另一種情況是絕對(duì)的)

FileSystemXmlApplicationContext ctx = ...; ctx.getResource("some/resource/path/myTemplate.txt"); FileSystemXmlApplicationContext ctx = ...; ctx.getResource("/some/resource/path/myTemplate.txt");

在實(shí)踐中，如果您需要真正的絕對(duì)文件系統(tǒng)路徑，您應(yīng)該避免將絕對(duì)路徑與FileSystemResource或FileSystemXmlApplicationContext一起使用，并通過(guò)使用file: URL前綴強(qiáng)制使用UrlResource。下面的例子演示了如何做到這一點(diǎn)

// actual context type doesn't matter, the Resource will always be UrlResource ctx.getResource("file:///some/resource/path/myTemplate.txt"); ApplicationContext ctx =new FileSystemXmlApplicationContext("file:///conf/context.xml");

參考文檔

總結(jié)

以上是生活随笔為你收集整理的spring核心技术之Resource资源理解的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。