spring_ioc的其他功能 (7.14节之后)

太过爱你忘了你带给我的痛 2022-01-16 10:25 152阅读 0赞

[2019独角兽企业重金招聘Python工程师标准>>> ][2019_Python_] ![hot3.png][]

\#\#\#7.14 Registering a LoadTimeWeaver 当类被加载到JVM中时,LoadTimeWeaver将动态转化类. 要使用运行时织入器,要在你的@Configuration类里添加@EnableLoadTimeWeaving注解.

@Configuration
    @EnableLoadTimeWeaving
    public class AppConfig {
    
    }

另一种方式是在xml配置里使用context:load-time-weaver元素:

当ApplicationContext一旦配置,任何在ApplicationContext内的实现了LoadTImeWeaverAware接口的Bean,会得到一个加载期织入器实例的引用.在聚合[Spring jpa support][] 时非常有用, 因为对JPA的类转译而言,运行时织入是必须的.查找LocalContainerEntityManagerFactoryBean的文档来了解更多.对于更多 AspectJ 加载期织入的,参看 [11.8.4 "load-time weaving with AspectJ in the Spring Framework"][11.8.4 _load-time weaving with AspectJ in the Spring Framework].

\#\#7.15 Additional Capabilities of the ApplicationContext(应用上下文的其他功能) 如同我们在章节介绍中讨论的,org.springframework.beans.factory包提供了管理和操作beans的基本功能,包括用编程方式.这个org.springframework.context包添加了ApplicationContext,它扩展了BeanFactory接口,并以更多的应用面相框架风格来提供更多的接口以实现更多的功能.许多人以完全声明的方式使用ApplicationContext,甚至不用程序创建它,而是依赖相关的额外支持类,如ContextLoader,用来自动实例化ApplicationContext,以作为java EE web应用正常启动流程的一部分.

要保证BeanFactory的功能更面向框架,那么上下文包也需要提供以下功能:

*  以 i18n-style(国际化) 的风格访问消息,通过MessageSource接口.
 *  访问资源,例如以URLS或文件,通过ResourceLoader接口.
 *  通过使用 ApplicationEventPublisher接口,事件可发布到以实现了ApplicationListener接口的已命名的bean中
 *  多层次上下文加载时,通过HierarchicalBeanFactory 接口,允许每个人只关注一个特定的层次,例如一个应用的web层;

\#\#\#7.15.1 Internationalization using MessageSource(通过消息资源实现国际化) ApplicationContext接口扩展了一个名为MessageSource的接口,并提供了国际化功能.spring还提供了HierarchicalMessagesource接口,它可以层次化处理消息.这些接口在一起构成了spring相应消息处理的基础.这些接口的方法包括:

*  String getMessage(String code,Object\[\] args,String default,Local loc):这是从MessageSource抓取消息的基本方法.当特定的位置没有发现消息时,默认的消息会使用.任何通过的参数变成特定值,可以使用标准类库里的messageFormat功能.
 *  String getMessage(String code,Object\[\] args,Locale loc):和上一个方法基本上是相同的,但有一点不同:因没有指定默认值,所有当没有消息被发现,一个NoSuchMessageException会被抛出.
 *  String getMessage(MessageSourceResolvable resolvable,Locale locale):上面方法所有的属性都会被包裹进一个名为MessageSourceResolvable的类里,你也可以使用这个方法替代.

当一个ApplicationContext被加载时,它会自动搜索每一个在上下文中定义的MessageSource的bean.这个Bean必须命名为messageSource.如果该bean被发现,上面所有对该消息资源的方法的调用都是代理形式.如果没有发现消息资源,那么ApplicationContext将尝试寻找其上级的包含了相同名字的bean.如果这样,那么它会使用名为MessageSource的bean.如果ApplicationContext还是无法发现消息资源,一个空的DelegatingMessageSource将会实例化以用来接受上面方法的调用.

Spring提供了两种MessageSource的实现,ResourceBundleMessageSource和StaticMessageSource.二者都实现了HierarchicalMessageSource以处理嵌套消息.StaticMessageSource很少使用,但它提供了编程的方式向资源中添加消息.而ResourceBundleMessageSource如下使用:

<beans>
        <bean id="messageSource"
                class="org.springframework.context.support.ResourceBundleMessageSource">
            <property name="basenames">
                <list>
                    <value>format</value>
                    <value>exceptions</value>
                    <value>windows</value>
                </list>
            </property>
        </bean>
    </beans>

上面的例子中表明你在类路径里有三种资源绑定定义,名字为:format,exceptions ,windows.任何释放消息的请求,会被通过ResourceBundeles以JDK标准释放消息的方式来处理.对于这些例子的目标,假设以下两种资源绑定文件的内容如下:

# in format.properties
    message=Alligators rock!
    
    # in exceptions.properties
    argument.required=The {0} argument is required.

下面的例子展示的是一段执行MessageSOurce功能的程序.记住所有ApplicationCOntext的实现同时也是MessageSource的实现,可以转化为MessageSource接口.

public static void main(String[] args) {
        MessageSource resources = new ClassPathXmlApplicationContext("beans.xml");
        String message = resources.getMessage("message", null, "Default", null);
        System.out.println(message);
    }

输出的结果如下:

Alligators rock!

所有来回顾下,在beans.xml里定义的MessageSource,该文件存在于类路径的根路径下.messageSource的bean定义通过它的basenames属性指向大量的资源定义.这三个在beannames属性列表里的的文件存在于你的类路径的根节点下,分别是format.properties,exceptions.properties,windows.properties.

下面的例子让我看下消息查找的参数,这些参数会转化到String中,并插入到查找消息的占位符里.

通过xml,设置参数依赖,将messageSource注入到example的Bean中;

public class Example {
    
        private MessageSource messages;
    
        public void setMessages(MessageSource messages) {
            this.messages = messages;
        }
    
        public void execute() {
            String message = this.messages.getMessage("argument.required",
                new Object [] {"userDao"}, "Required", null);
            System.out.println(message);
        }
    
    }

这个输出结果是:

The userDao argument is required.

关于国际化,spring的各种MessageSource实现遵循和标准JDK ResourceBundle一样的场景方案和回滚规则.继续上面的messageSource的定义.如果你要在英文场景下释放这些消息,简单的说,你需要分别创建这三个文件,format\_en\_GB.properties,exceptions\_en\_GB.properties,windows\_en\_GB.properties.

一般而言,场景解决主要有应用的周边环境来管理.在本例中,消息的英文场景会手动指定;

# in exceptions_en_GB.properties
    argument.required=Ebagum lad, the {0} argument is required, I say, required.
    
    public static void main(final String[] args) {
        MessageSource resources = new ClassPathXmlApplicationContext("beans.xml");
        String message = resources.getMessage("argument.required",
            new Object [] {"userDao"}, "Required", Locale.UK);
        System.out.println(message);
    }

上面例子的输出结果为:

Ebagum lad, the 'userDao' argument is required, I say, required.

你可以使用MessageSourceAware接口来获得一个已经定义了的MessageSource接口的引用.定义在ApplicationContext中实现了MessageSourceAware接口的bean,当它们创建时会自动注入应用上下文的MessageSource.

作为ResourceBundleMessageSource的替换,spring提供了一个ReloadableResourceBundleMessageSource类.这个变种支持相同的文件绑定格式,但比基于标准JDK的ResourceBundleMessageSource实现要更加灵活.特别,它允许从任何spring的资源位置(不仅仅类路径)读取文件,并支持对绑定属性文件的热重载(重载期间有效的缓冲).查看ReloadableResourceBundleMessageSource文档来确定更多细节.

\#\#\#7.15.2 Standard and Custom Events (标准和自定义事件) 在ApplicationCOntext中的事件处理是通过ApplicationEvent类和ApplicationListener接口来实现的.如果有一个实现了ApplicationListener接口的bean部署到上下文中,每当一个ApplicationEvent发布到ApplicationContext时,这个bean会被调用.基本上,这就是标准的Observer(观察者)设计模式;

在spring4.2后,事件组件得到了明显的提升,并提供了基于注解的模式已发布任意事件,也就说一个对象没有必要继承ApplicationEvent类.当符合条件的对象发布时,我们为你将该对象包装到一个事件里;

spring提供了一下标准事件. \#\#\#Built-in Events ![输入图片说明][21095305_SMc8.png]![输入图片说明][21095322_ss9j.png] \#\#\#\#ContextRefreshedEvent 上下文刷新事件

当ApplicationContext已初始化或已刷新时,会发布.例如,使用ConfigurableApplicationContext接口中的refresh()方法."initialized"意味着所有的bean都已被加载,后处理器的bean都被检测和启动,单例bean都被提前实例化,且ApplicationContext对象已做好准备使用.只要上下文没被关闭,有特定的ApplicationContext提供的热刷新,可以被触发很多次.

\#\#\#\#ContextStartedEvent 上下文启动事件 发布:当ApplicationContext启动,会使用ConfigurableApplicationContext接口里的start()方法."Started"意味着所有生命周期的bean收到了一个明确的启动信号.一般而言,这个信号只用来在一个明确的停止后重启beans,但是它可以被用来启动一些没被设置为自动启动的bean,例如一些在初始化中没被启动的组件. \#\#\#\#ContextStoppedEvent 上下文停止事件

当使用ConfigurableApplicationContext接口中的stop()方法时,上下文就会停止,事件发布."Stopped"这里指所有的生命周期的beans都会受到一个明确的停止信号.一个停止的上下文可以通过start()方法重启.

#### ContextClosedEvent 上下文关闭事件 ####

当调用ConfigurableApplicationContext接口的close()方法时,ApplicationContext就会关闭,事件就会发布."Closed"这里指的是所有的单例bean都会被销毁.一个关闭的上下文已到达它生命的端点,他不可能被刷新或重启.

#### RequestHandledEvent 请求处理事件 ####

一个特定的web事件,告诉所有的bean要为一个HTTP请求提供服务.当请求拼完后这个事件就会发布.这个事件只有当一个web应用使用spring的DispatcherServlet服务时才适用.

你可以创建和发布你的自定义事件.这个例子展示了一个扩展了Spring ApplicationEvent基类的简单类.

public class BlackListEvent extends ApplicationEvent {
    
        private final String address;
        private final String test;
    
        public BlackListEvent(Object source, String address, String test) {
            super(source);
            this.address = address;
            this.test = test;
        }
    
        // accessor and other methods...
    
    }

要发布一个自定义事件,需要调用ApplicationEventPublisher实例上的publishEvent()方法.一般而言,可以通过实现ApplicationEventPublisherAware来创建一个类并将它注册为一个spring bean.下面的例子展示如何使用这个类:

public class EmailService implements ApplicationEventPublisherAware {
    
        private List<String> blackList;
        private ApplicationEventPublisher publisher;
    
        public void setBlackList(List<String> blackList) {
            this.blackList = blackList;
        }
    
        public void setApplicationEventPublisher(ApplicationEventPublisher publisher) {
            this.publisher = publisher;
        }
    
        public void sendEmail(String address, String text) {
            if (blackList.contains(address)) {
                BlackListEvent event = new BlackListEvent(this, address, text);
                publisher.publishEvent(event);
                return;
            }
            // send email...
        }
    
    }

在配置期间,spring容器会检测到EmailService实现了ApplicationEventPublisherAware接口,并自动调用setApplicationEventPublisher()方法.实际上,传入的参数将是spring容器自身;你可以通过ApplicationEventPublisher接口来简单的同应用上下文交互.

要接受一个自定义ApplicationEvent事件,需创建一个实现了ApplicationListener接口的类并注册它为bean.下面的例子展示了一个这样的类:

public class BlackListNotifier implements ApplicationListener<BlackListEvent> {
    
        private String notificationAddress;
    
        public void setNotificationAddress(String notificationAddress) {
            this.notificationAddress = notificationAddress;
        }
    
        public void onApplicationEvent(BlackListEvent event) {
            // notify appropriate parties via notificationAddress...
        }
    
    }

可以发现ApplicationListener通常是通过你的自定义事件的类型(BlackListEvent类)来泛型化参数的.这意味着onApplicationEvent()方法可以保持类型安全,避免进行向下转型.你可以注册非常多的监听器,但要记住事件监听器默认会进行同步监听.这意味着只有当所有的监听器处理完这个事件之后,publishEvent()方法才会停止.这种同步和单线程处理的优点之一是:如果一个监听器接受到事件,当它能从发布者那里获得一个事务上下文,那它会在上下文里处理事件.如果有必要使用其他的事件发布策略,查看spring的ApplicationEventMulticaster接口.

下面的例子展示了用来注册和配置每个类的bean定义.

<bean id="emailService" class="example.EmailService">
        <property name="blackList">
            <list>
                <value>known.spammer@example.org</value>
                <value>known.hacker@example.org</value>
                <value>john.doe@example.org</value>
            </list>
        </property>
    </bean>
    
    <bean id="blackListNotifier" class="example.BlackListNotifier">
        <property name="notificationAddress" value="blacklist@example.org"/>
    </bean>

整合所有,当emailService的bean的sendEmail()方法被调用时,如果有一个email是黑名单中,一个BlackListEvent类型的自定义事件就会被发布.而blackListNotifier的bean被注册为ApplicationListener(应用监听器)被会接受这个BlackListEvent事件,此时它就会通知适当的部分.

spring的事件机制主要用于同一应用上下文中spring bean之间的简单交互.但是,对于更加复杂的企业集成需求,这个分布式的spring集成项目提供了对基于spring编程模式来搭建轻量级,[面向模式][Link 1],事件驱动的架构的全面支持.

\#\#\#\#Annotation--based Event Listeners 基于注解的事件监听器 在spring4.2之后,一个事件监听器可以通过在一个受管理的bean里的一个公共方法上添加EventListener注解来注册.这个BlackListNotifier可以如下重写:

public class BlackListNotifier {
    
        private String notificationAddress;
    
        public void setNotificationAddress(String notificationAddress) {
            this.notificationAddress = notificationAddress;
        }
    
        @EventListener
        public void processBlackListEvent(BlackListEvent event) {
            // notify appropriate parties via notificationAddress...
        }
    
    }

如同上面我们看到的,这个方法时间上参考你要监听的事件类型.只要一个实际的事件发布,你就要拦截该泛型参数,只有符合内嵌的泛型,该方法才会工作.

如果你要拦截几种事件类型,又或者你不打算指定方法的参数,这个事件类型可以在注解上指定;

@EventListener({ContextStartedEvent.class, ContextRefreshedEvent.class})
    public void handleContextStart() {
    
    }

我们可以通过注解的condition属性来添加额外的运行时拦截条件,该属性定义了一个SpEL表达式,你需要匹配这个特定事件,才能调用相应的方法.

例如,我们的通知器可以重写为只有当事件的test属性等于foo时才会调用.

@EventListener(condition = "#event.test == 'foo'")
    public void processBlackListEvent(BlackListEvent event) {
        // notify appropriate parties via notificationAddress...
    }

每一次SpEL表达式评估都有专门的上下文.下面的表格展示了你在该上下文中能获得的选项,所有你可以使用他们进行有条件的事件处理:

\#\#\#\#Event Spel available metadata ![输入图片说明][21101216_O0sd.png] 名称:event 位置:root object 描述:实际的ApplicationEvent(应用事件),例子:\#root.event

名称:args 位置:root Object 描述:调用目标使用的参数(数组) 例子:\#root.args\[0\]

名称:argument name 位置:evaluation context 描述:方法中每个参数的名字.如果因某些原因这些名字不可获得,这个参数的名称仍可以通过\#a<\#arg>来获取,这个\#arg代表的是参数的下标(从0开始). 例子:\#iban或\#a0(也可以使用\#p0或使用\#p<\#arg>标志作为别名)

记住\#root.event允许你访问对应的事件,即使你的方法签名实际上对应的是任意要发布的对象.

如果你因为处理完某个事件后需要发布一个新事件,只需要把方法签名的返回修改为你需要发布的事件的类型,像这样:

@EventListener
    public ListUpdateEvent handleBlackListEvent(BlackListEvent event) {
        // notify appropriate parties via notificationAddress and
        // then publish a ListUpdateEvent...
    }

该功能不支持[异步的监听器][Link 2];

这个新方法会为每个该方法处理过的blackListEvent发布一个新的ListUpdateEvent事件.如果你需要发布几个事件,只需要返回这些事件的集合.

\#\#\#\#Asynchronous Listeners 同步监听器

如果你想要一个特别的监听器来异步处理事件,简单的使用常规的@Async支持:

@EventListener
    @Async
    public void processBlackListEvent(BlackListEvent event) {
        // BlackListEvent is processed in a separate thread
    }

记住使用异步事件时注意以下几个局限:

*  1.如果监听器抛出一个异常,它不会传播到调用者那里.查看AsyncUncaughtExceptionHandler以应对更多细节.
 *  2.这些事件监听器无法发送回复.如果你需要发送其他事件作为处理结果,注入ApplicationEventPublisher进行手动发送.

\#\#\#\#Ordering Listeners 监听器排序 如果你想要一个监听器先于其他调用.只需要在方法参数上添加@Order注解;

@EventListener
    @Order(42)
    public void processBlackListEvent(BlackListEvent event) {
        // notify appropriate parties via notificationAddress...
    }

\#\#\#\#Generic Events 泛型事件 你可以使用泛型更深入的定义你的事件的结构.思考一个EntityCreatedEvent<T>,其中T是被创建实体的实际类型.你可以创建一个只用来接受Person类的EntityCreatedEvent事件监听器;

@EventListener
    public void onPersonCreated(EntityCreatedEvent<Person> event) {
        ...
    }

由于类型擦除,只有当事件完好符合事件监听器拦截的泛型参数,它才工作.(这类似如class PersonCreatedEvent extends EntityCreatedEvent<Person>\{...\});

在特定的环境下,如果有所有的事件都遵循相同的结构(它可能是上面提到的那种事件)会变得相当乏味.这样的话,你可用实现ResolvableTypeProvider来指导运行时环境提供的架构.

public class EntityCreatedEvent<T>
            extends ApplicationEvent implements ResolvableTypeProvider {
    
        public EntityCreatedEvent(T entity) {
            super(entity);
        }
    
        @Override
        public ResolvableType getResolvableType() {
            return ResolvableType.forClassWithGenerics(getClass(),
                    ResolvableType.forInstance(getSource()));
        }
    }

它不仅只对ApplicationEvent事件其作用,还适用于你作为事件发布的任意对象.

\#\#\#7.15.3 Convenient access to low-level resources (有效的访问低级资源) 作为应用上下文的可选使用和理解,用户应该基本上通过Spring Resource abstraction 抽象来熟悉它们;同[第8章][8]所讲的;

一个应用上下文是一个资源加载器,可以用来加载Resource.一个资源本质上是JDK类中的java.net.URL类的更多功能的变种.实际上,java.net.Resource的实现以合适的方式来包装URL的实例.一个Resource可以以透明的方获取低层次的资源,包括类路径,文件系统位置,任何能被标准RUL描述的资源,或者其他类型.如果这个资源位置字符串是一个不带任何前缀的简单路径,这些资源来自于特定和合适的实际应用上下文类型.

你可以配置一个bean部署到应用上下文中来实现指定的回调接口->ResourceLoaderAware,在应用上下文初始化时会作为ResourceLoader而自动回调.你可以暴露Resource类型的属性,以用来访问静态资源;他们也可以像其他属性一样被注入.你可以将这些Resource属性指定为简单的字符串路径,它依赖的一个特定的JavaBean是PropertyEditor已被自动注册到上下文中,该javaBean部署之后可以将文本字符串转化为时间的资源对象.

这个提供给ApplicationContext构造器的位置路径是真实的资源字符串,并以简单的方式妥善的被特定的上下文实现进行处理.ClassPathXmlApplicationContext可以把一个简单的位置路径作为一个类路径位置.你也可以使用带具体前缀的位置路径来从类路径或URL来强制加载定义,而忽略实际的上下文类型.

\#\#\#7.15.4 Convienent ApplicationContext instantiation for web applications 例如,你可以使用一个ContextLoader创建一个ApplicationContext实例.当然你也可以使用ApplicationContext的某个实现来动态创建ApplicationContext的一个实例.

你可以如下使用ContextLoaderListener来注册一个ApplicationContext:

<context-param>
        <param-name>contextConfigLocation</param-name>
        <param-value>/WEB-INF/daoContext.xml /WEB-INF/applicationContext.xml</param-value>
    </context-param>
    
    <listener>
        <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
    </listener>

监听器会检验上下文配置位置的参数.如果参数不存在,那么监听器会默认使用/WEB-INF/applicationContext.xml.当参数存在,那这个监听器户会通过已定义的分隔符(逗号,分号,空白符)来分割该字符串,并将这些值作为作为应用上下文要查询的位置.Ant风格的匹配符同样支持.例如/WEB-INF/\*Context.xml可用于所有以Context.xml结尾的文件.如果存在于"WEB\_INF"目录,并为/WEB-INF/\*\*/\*Context.xml,那么使用于所有"WEB-INF"下的子目录;

\#\#\#7.15.5 Deploying a Spring ApplicationContext as a Java EE RAR file (以java EE RAR文件来部署spring应用上下文) 你可以把spring应用上下文作为一个RAR文件来部署,包括这个上下文和它所有必须的bean类,以及部署在java EE RAR部署单元里的类库JAR包.这等同在一个单独的ApplicationContext,在一个java EE环境里,可以访问java EE服务设施.RAR部署的是无需处理的WAR文件部署的另一个更加自然的替代物,实际上,一个WAR文件无需任何HTTP接触点就可以启动并只能用于在java EE环境里启动一个spring应用上下文.

RAR部署对于应用上下文来说很理想,不需要http触发点,只需要一些消息端点和定时任务.上下文中的Beans也可以使用应用服务器的资源,例如JTA事务管理,JNDI-bound JDBC DataSources,JMS ConnectionFactory instance,或许还有已通过平台注册的JMX服务器;都是通过spring标准事务管理和JNDI,JMX支持组件实现的.应用组件也可以通过spring的TaskExecutor抽象同应用服务器的JCA工作管理器交互.

查看SpringContextResourceAdapter类的文档来获取RAR部署的更多细节.

简单把一个spring应用上下文做为一个java EE RAR文件部署:打包所有的应用类到一个RAR文件里,这是一个有不同文件扩展名的标准JAR文件.在RAR结构里的根位置里添加所有必须的类库JARs.添加一个"META-INF/ra.xml"部署描述器(在SpringContextResourceAdapter的文档里有描述)和对应的spring xml bean定义的文件(一般是META-INF/applicationContext.xml文件),并把生成的RAR文件剪贴到应用服务器的部署目录.

这些RAR部署单元通常有很强的独立性,它们不会向外界暴露接口,就是同一应用的其他模块也不行.(像电网UAP项目里的模块项目一样);基于RAR的应用上下文之间的交互是通过与其他模块共享的JMS端点来实现的.一个基于RAR的系统也可以有其他功能:例如,安排些任务,对文件系统里的新文件做些反应.如果它需要和外界进行同步交互,它允许你导出RMI 端点,当然这也适用于同一机制下的其他应用模块.

\#\#7.16 The BeanFactory BeanFactory提供了spring ioc功能的基础,但现在它只在集成第三方框架和spring的老用户直接使用.BeanFactory和相关的接口,例如BeanFactoryAware,InitializingBean,DisposableBean等依然在spring中存在,主要是为了照顾spring中集成的第三方框架的向后兼容性.一般第三方的组件无法使用太新的的东西,比如@PostConstruct或@PreDestroy,因此要保持对jdk1.4的兼容或避免使用JSR-250的依赖.

这部分介绍了BeanFactory和ApplicationContext的差异的 额外背景,以及如何通过一个类的单例查找来访问IOC容器. \#\#\#7.16.1 BeanFactory or ApplicationContext? 除非你有更好的理由,否则请使用ApplicationContext;

因为ApplicationContext包含了所有BeanFactory的功能;建议使用BeanFactory的情况一般是:在一个资源受限的应用上运行项目,因为此时资源开销会非常重要,即使几KB也会导致极大不同.但是,对于绝大多数典型的企业应用和系统来言,你还是需要ApplicationContext的.spring大量使用了BeanPostProcessor 的extension point(进行高效代理或其他).假如你只使用简单的BeanFactory,如事务管理和AOP等很多支持将不起作用,至少在你的代码里不会有额外的步骤.这种情况会令你困惑,因为你的配置里没有其他错误.

下面列表提供了BeanFactory和ApplicationContext接口和实现提供的功能;

BeanFactory : 1; ApplicationContext:2

*  Bean instantiation/wiring 1:yes 2:yes
 *  Automatic BeanPostProcessor registration 1:NO, 2:yes
 *  Automatic BeanFactoryPostProcessor registration 1:no 2:yes
 *  Convenient MessageSource access(for i18n) 1:no 2:yes -ApplicationEvent publication 1:no 2:yes

要明确使用BeanFactory实现来注册一个后处理器,你需要这样编码:

DefaultListableBeanFactory factory=new DefaultListableBeanFactory();
    
    // populate the factory with bean definitions
    
    // now register any needed BeanPostProcessor instances
    MyBeanPostProcessor postProcessor = new MyBeanPostProcessor();
    factory.addBeanPostProcessor(postProcessor);
    
    // now start using the factory

要使用BeanFactory实现来注册一个BeanFactoryPostProcessor,你需要这么写:

DefaultListableBeanFactory factory = new DefaultListableBeanFactory();
    XmlBeanDefinitionReader reader = new XmlBeanDefinitionReader(factory);
    reader.loadBeanDefinitions(new FileSystemResource("beans.xml"));
    
    // bring in some property values from a Properties file
    PropertyPlaceholderConfigurer cfg = new PropertyPlaceholderConfigurer();
    cfg.setLocation(new FileSystemResource("jdbc.properties"));
    
    // now actually do the replacement
    cfg.postProcessBeanFactory(factory);

在这些步骤中,具体的注册步骤并不重要;这也是大部分各种ApplicatinContext实现更倾向基于使用BeanFactory来实现,特别是当使用BeanFactoryPostProcessor和BeanPostProcessor时.这些机制实现了非常重要的功能,如属性替代符替换和AOP;

\#\#\#7.16.2 Glue code and the evil singleton (大泥球代码和讨厌单例) 你最好使用依赖注入(DI)的风格来写应用代码,这些代码将由spring ioc提供服务,在其创建时就会得到容器提供的依赖,且完全不须知道容器.但是,对于一小部分胶水层的代码,它们需要和其他代码连接在一起,有时你需要单例(等同单例)风格来访问spring ioc的容器.例如,第三方的代码会不管是否能从spring的ioc容器里获得这些对象而直接尝试创建新的对象(Class.forName()风格).如果被第三方代码构造的是一个小的存根或代理,它可以使用单例风格来访问spring ioc容器来得到它要代理的实际对象,那么控制反转对于大部分代码(容器之外生成的对象)来说还是可以使用.因为这些代码仍不需要关心容器或关心如何访问它,保持了和其他代码的解耦,并保持必要的便利.EJBs也可以使用这种stub/proxy方式从spring ioc容器里获取 一个简单java对象的代理.然而spring ioc容器自身最好不是必须是个单例bean,这不现实;因为每个bean来使用自己容器的内存开销或初始化时间是(当使用spring IOC容器里的bean例如一个hibernate的SessionFactory)不一样,所有最好是非单例的spring IOC容器.

以服务定位的风格来查找应用上下文有时是访问公共spring-managed 组件的唯一方式,例如在一个EJB2.1环境,又或者当你想分享一个单例应用上下文作为WAR文件里的父级webApplicationContexts.这种情况下你应该使用[springteam blog entry][]里描述的有用类ContextSingleBeanFactoryLocator定位器

--------------------

Resource抽象,java.net.URL,ResourceLoader,ResourceLoaderAware;contextConfigLocation;RAR文件,JTA;BeanFactory,glue code ,evil singleton

转载于:https://my.oschina.net/u/1590027/blog/761375

[2019_Python_]: https://my.oschina.net/u/2663968/blog/3061697
[hot3.png]: /images/20220114/d3dcbcd8f21d4fa5a1ee02f3dea3052e.png
[Spring jpa support]: http://docs.spring.io/spring/docs/current/spring-framework-reference/htmlsingle/#orm-jpa
[11.8.4 _load-time weaving with AspectJ in the Spring Framework]: http://docs.spring.io/spring/docs/current/spring-framework-reference/htmlsingle/#aop-aj-ltw
[21095305_SMc8.png]: https://static.oschina.net/uploads/img/201610/21095305_SMc8.png
[21095322_ss9j.png]: https://static.oschina.net/uploads/img/201610/21095322_ss9j.png
[Link 1]: http://www.enterpriseintegrationpatterns.com/
[21101216_O0sd.png]: https://static.oschina.net/uploads/img/201610/21101216_O0sd.png
[Link 2]: http://docs.spring.io/spring/docs/current/spring-framework-reference/htmlsingle/#context-functionality-events-async
[8]: http://docs.spring.io/spring/docs/current/spring-framework-reference/htmlsingle/#resources
[springteam blog entry]: https://spring.io/blog/2007/06/11/using-a-shared-parent-application-context-in-a-multi-war-spring-application/