学步园

     Spring提供了一套基于org.springframework.core.io.Resource和org.springframework.core.io.ResourceLoader接口的资源抽象和加载策略。

     Spring框架内部使用org.springframework.core.io.Resource接口作为所有资源的抽象和访问接口。其中ClassPathResource就是Resource的一个特定类型的实现，代表的是位于Classpath中的资源。Resource接口可以根据资源的不同类型，或者资源所处的不同场合，给出相应的具体实现。可以在org.springframework.core.io包下找到这些实现类。

     org.springframework.core.io.ResourceLoader接口是资源查找定位策略的统一抽象，具体的资源查找定位策略则由相应的ResourceLoader实现类给出。

ResourceLoader有一个默认的实现类，即org.springframework.core.io.DefaultResourceLoader。

     FileSystemResourceLoader继承自DefaultResourceLoader，但覆写了getResourceByPath(String)方法，使之从文件系统加载资源并以FileSystemResource类型返回。

     ResourcePatternResolver是ResourceLoader的扩展，ResourceLoader每次只能根据资源路径返回确定的单个Resource实例，而ResourcePatternResolver则可以根据指定的资源路径匹配模式，每次返回多个Resource实例。ResourcePatternResolver在继承ResourceLoader原有定义的基础上，又引入了Resource[]
getResources(String)方法定义，以根据路径匹配模式返回多个Resource的功能。

     ApplicationContext继承了ResourcePatternResolver，当然就间接实现了ResourceLoader接口。所以，任何的ApplicationContext实现都可以看作是一个ResourceLoader甚至ResourcePatternResolver。而这就是ApplicationContext支持Spring内统一资源加载策略的真相。

     对于Java中的国际化信息处理，主要涉及两个类，即java.util.Locale和java.util.ResourceBundle。

     不同的Locale代表不同的国家和地区，每个国家和地区在Locale这里都有相应的简写代码表示，包括语言代码以及国家代码，这些代码是ISO标准代码。

     ResourceBundle用来保存特定于某个Locale的信息。ResourceBundle管理一组信息序列，所有的信息序列有统一的一个basename，然后特定的Locale的信息，可以根据basename后追加的语言或者地区代码来区分。

     按照规定，properties文件内容是以ISO-8859-1编码的，所以，实际上message_zh_CN.properties中各个键对应的内容是不应该以中文提供的，应该使用native2ascii或者类似的相关工具进行转码。

     有了ResourceBundle对应的资源文件之后，我们就可以通过ResourceBundle的getBundle(String basename, Locale locale)方法取得不同Locale对应的ResourceBundle，然后根据资源的键取得相应Locale的资源条目内容。

     通过结合ResourceBundle和Locale，我们就能够实现应用程序的国际化信息支持。

     Spring在Java SE的国际化基础上，进一步抽象了国际化信息的访问接口，也就是org.springframework.context.MessageSource。ApplicationContext除了实现ResourceLoader以支持统一的资源加载，它还实现了MessageSource接口，那么就跟ApplicationContext因为实现了ResourceLoader而可以当作ResourceLoader来使用一样，ApplicationContext也是一个MessageSource了。

    Spring提供了三种MessageSource的实现，即StaticMessageSource、ResourceBundleMessageSource和ReloadableResourceBundleMessageSource。具体实现的细节可以查看相关的JavaDoc。使用ReloadableResourceBundleMessageSource时，应该避免将信息资源文件放到classpath中，因为这样无助于ReloadableResourceBundleMessageSource定期加载文件变更。

     Spring的ApplicationContext容器提供的容器内事件发布功能，是通过提供一套基于Java SE标准自定义事件类而实现的。

     Java SE提供了实现自定义事件发布（Custom Event Publication）功能的基础类，即java.util.EventObject类和java.util.EventListener接口。所有的自定义事件类型可以通过扩展EventObject来实现，而事件的监听器则扩展自EventListener。

     Java SE中标准的自定义事件实现就是下面这个样子，基本上涉及三个角色，即自定义的事件类型、自定义的事件监听器和自定义的事件发布者：

    Spring的ApplicationContext容器内部允许以org.springframework.context.ApplicationEvent的形式发布事件，容器内注册的org.springframework.context.ApplicationListener类型的bean定义会被ApplicationContext容器自动识别，他们负责监听容器内发布的所以ApplicationEvent类型的事件。

    Spring容器内自定义的事件内心，继承自java.util.EventObject，它是一个抽象类，需要根据情况提供相应子类以区分不同情况。

    Spring容器内使用的自定义事件监听器接口定义，继承自java.util.EventListener。ApplicationContext容器在启动的时候，会自动识别并加载EventListener类型的bean定义，一旦容器内有事件发布，将通知到这些注册到容器的EventListener。

    除了ResourceLoader和MessageSource接口，ApplicationContext接口定义还继承了ApplicationEventPublisher接口，该接口提供了void publishEvent(ApplicationEvent event)方法定义。ApplicationContext容器现在担当的就是事件发布者的角色。

    ApplicationContext容器具体实现类在实现事件的发布和事件监听器的注册方面，并没有事必躬亲，而是把这些活儿转包给了一个称作org.springframework.context.event.ApplicationEventMulticaster的接口。该接口定义了具体事件监听器的注册管理以及事件发布的方法。ApplicationEventMulticaster有一个抽象实现类——org.springframework.context.event.AbstractApplicationEventMulticaster，它实现了事件监听器的管理功能。