<beans> Spring配置文件的根元素,包含一个或多个bean元素。
<bean> 用于告诉Spring容器一个类以及它是如何配置的。
class属性:Java Bean 类名(全路经)。
id属性:Java Bean在BeanFactory中的唯一标识,代码中通过BeanFactory获取JavaBean实例时需以此作为索引名称。
name属性:同上,如果给bean增加别名,可以通过name属性指定一个或多个id。
singleton属性:指定此Java Bean是否采用单例(Singleton)模式,如果设为“true”,则在BeanFactory作用范围内,只维护此Java Bean的一个实例,代码通过BeanFactory获得此Java Bean实例的引用。反之,如果设为“false”,则通过BeanFactory获取此Java Bean实例时,BeanFactory每次都将创建一个新的实例返回。
abstract属性:设定ApplicationContext是否对bean进行预先的初始化。
parent属性:定义一个模板。
autowire属性:bean自动装配模式。可选5种模式。
no:不使用自动装配。
Bean的引用必须通过ref元素定义。byName:通过属性名字进行自动装配。
byType:如果BeanFactory中正好有一个同属性类型一样的bean,就自动装配这个属性。如果有多于一个这样的bean,就抛出一个致命异常,它指出你可能不能对那个bean使用byType的自动装配。如果没有匹配的bean,则什么都不会发生,属性不会被设置。如果这是你不想要的情况(什么都不发生),通过设置dependency-check="objects"属性值来指定在这种情况下应该抛出错误。
constructor:这个同byType类似,不过是应用于构造函数的参数。如果在BeanFactory中不是恰好有一个bean与构造函数参数相同类型,则一个致命的错误会产生。
autodetect: 通过对bean 检查类的内部来选择constructor或byType。如果找到一个缺省的构造函数,那么就会应用byType。
dependency-check属性:依赖检查模式。可选四种。
none :不进行依赖检查。没有指定值的bean属性仅仅是没有设值。
Simple:对基本类型和集合(除了合作者外,比如其他的bean,所有东西)进行依赖检查。
Object:对合作者进行依赖检查。
all :对合作者,基本类型和集合都进行依赖检查。
lazy-init属性:延迟加载。True 或False 。
init-method属性:初始化方法,此方法将在BeanFactory创建JavaBean实例之后,在向应用层返回引用之前执行。一般用于一些资源的初始化工作。
destroy-method属性:销毁方法。此方法将在BeanFactory销毁的时候执行,一般用于资源释放。 factory-bean属性:通过实例工厂方法创建bean,class属性必须为空,factory-bean属性必
须指定一个bean的名字,这个bean一定要在当前的bean工厂或者父bean工厂中,并包含工厂方法。而工厂方法本身通过factory-method属性设置。
factory-method属性:设定工厂类的工厂方法。
depends-on属性:Bean依赖关系。一般情况下无需设定。Spring会根据情况组织各个依赖关系的构建工作。只有某些特殊情况下,如JavaBean中的某些静态变量需要进行初始化(这是一种BadSmell,应该在设计上应该避免)。通过depends-on指定其依赖关系可保证在此Bean加载之前,首先对depends-on所指定的资源进行加载。
<property> 用于设置一个属性。
name属性: 属性的名称。
<value> 指定bean的属性值。
<ref> 指定了属性对BeanFactory中其他Bean的引用关系。
bean=""属性:指定了属性对BeanFactory中其他Bean的引用关系。
local属性:local=""属性: 指定了属性对BeanFactory中其他Bean的引用关系。(仅在本地(同一个)xml文件里寻找bean。
parent属性:指定了属性对BeanFactory中其他Bean模板的引用关系。
<list> 指定bean的属性类型为List的属性值。
<map> 指定bean的属性类型为List的属性值。
<set> 指定bean的属性类型为List的属性值。
<props> 指定bean的属性类型为Properties的属性值。
<prop>
key属性:指定Properties的键
<idref> 用来设置属性值为容器中其他bean的id 或name。
<null> 指定一个空值。
<constructor-arg> 使用构造方法注入,指定构造方法的参数。
index属性:设置参数的序号。
ref属性:同ref
type属性:参数类型。
value属性:参数的值。
<lookup-method> lookup方法注入
bean属性:要注入的bean名
name属性:要注入的方法名称
<replaced-method> 用来把已存在的方法实现替换为其他的实现。
name属性:要替换的方法名
replacer属性:替换者类, 实现org.springframework.beans.factory.support.MethodReplacer
接口)
<arg-type> 方法返回的类型
<bean id="exampleBean" class="examples.ExampleBean">
<constructor-arg type="int" value="7500000"/>
<constructor-arg type="java.lang.String" value="42"/>
</bean>
引用:使用index属性除了可以解决多个简单类型构造参数造成的模棱两可的问题之外,还可以用来解决两个构造参数类型相同造成的麻烦。注意:index属性值从0开始。
<bean id="exampleBean" class="examples.ExampleBean">
<constructor-arg index="0" value="7500000"/>
<constructor-arg index="1" value="42"/>
</bean>
以上的两种构造器注入一种用的类型,一种用的索引
引用其他Bean
这里有三种引用的方法,<ref bean="someBean"/>
<ref local="someBean"/>
<ref parent="accountService"/>很少使用
经过试验证明<ref local="someBean"/> 这种方法只有在当前的Xml文件中才能起到作用,使用引用标记
<import resource="teama-applicationContext.xml"/>
不能起作用,会抛出异常。
3.3.3.4.1集合合并
<beans>
<bean id="parent" abstract="true" class="example.ComplexObject">
<property name="adminEmails">
<props>
<prop key="administrator">administrator@somecompany.com</prop>
<prop key="support">support@somecompany.com</prop>
</props>
</property>
</bean>
<bean id="child" parent="parent">
<property name="adminEmails">
<!-- the merge is specified on the *child* collection definition -->
<props merge="true">
<prop key="sales">sales@somecompany.com</prop>
<prop key="support">support@somecompany.co.uk</prop>
</props>
</property>
</bean>
<beans>
在上面的例子中,childbean的adminEmails属性的<props/>元素上使用了merge=true属性。当child bean被容器实际解析及实例化时,其 adminEmails将与父集合的adminEmails属性进行合并。
最终:administrator=administrator@somecompany.com
sales=sales@somecompany.com
support=support@somecompany.co.uk
3.3.3.4.2. 强类型集合(仅适用于Java5+)
public class Foo {
private Map<String, Float> accounts;
public void setAccounts(Map<String, Float> accounts) {
this.accounts = accounts;
}
}
<beans>
<bean id="foo" class="x.y.Foo">
<property name="accounts">
<map>
<entry key="one" value="9.99"/>
<entry key="two" value="2.75"/>
<entry key="six" value="3.99"/>
</map>
</property>
</bean>
</beans>
在foobean的accounts属性被注入之前,通过反射,利用强类型Map<String, Float>的泛型信息,Spring的底层类型转换机制将会把各种value元素值转换为Float类型,因此字符串9.99、2.75及3.99就会被转换为实际的Float类型。
<bean class="ExampleBean">
<property name="email"><null/></property>
</bean>
上述的配置等同于Java代码:exampleBean.setEmail(null)。
3.3.3.6. XML-based configuration metadata shortcuts(Xml的简写)
<property name="myProperty" value="hello"/>
<constructor-arg value="hello"/>
<entry key="myKey" value="hello"/>
<property name="myProperty" ref="myBean"/>
<constructor-arg ref="myBean"/>
注意,尽管存在等同于<ref bean="xxx"> 元素的简写形式,但并没有<ref local="xxx">的简写形式,为了对当前xml中bean的引用,你只能使用完整的形式。
<entry>
<key>
<ref bean="myKeyBean" />
</key>
<ref bean="myValueBean" />
</entry>
等同于:
<entry key-ref="myKeyBean" value-ref="myValueBean"/>
当设置bean的组合属性时,除了最后一个属性外,只要其他属性值不为null,组合或嵌套属性名是完全合法的。例如,下面bean的定义:
<bean id="foo" class="foo.Bar">
<property name="fred.bob.sammy" value="123" />
</bean>
foo bean有个fred属性,此属性有个 bob属性,而bob属性又有个sammy属性,最后把sammy属性设置为123。为了让此定义能工作, foo的fred属性及fred 的bob属性在bean被构造后都必须非空,否则将抛出NullPointerException异常。
若需要表达对多个bean的依赖,可以在'depends-on'中将指定的多个bean名字用分隔符进行分隔,分隔符可以是逗号、空格及分号等。下面的例子中使用了'depends-on'来表达对多个bean的依赖。
<bean id="beanOne" class="ExampleBean" depends-on="manager,accountDao">
<property name="manager" ref="manager" />
</bean>
<bean id="manager" class="ManagerBean" />
<bean id="accountDao" class="x.y.jdbc.JdbcAccountDao" />
3.3.5. 延迟初始化bean
ApplicationContext实现的默认行为就是在启动时将所有singleton bean提前进行实例化。提前实例化意味着作为初始化过程的一部分,ApplicationContext实例会创建并配置所有的singleton bean。通常情况下这是件好事,因为这样在配置中的任何错误就会即刻被发现(否则的话可能要花几个小时甚至几天)。
有时候这种默认处理可能并不是你想要的。如果你不想让一个singleton bean在ApplicationContext实现在初始化时被提前实例化,那么可以将bean设置为延迟实例化。一个延迟初始化bean将告诉IoC 容器是在启动时还是在第一次被用到时实例化。
在XML配置文件中,延迟初始化将通过<bean/>元素中的lazy-init属性来进行控制。
<bean id="lazy" class="com.foo.ExpensiveToCreateBean" lazy-init="true">
</bean>
<bean name="not.lazy" class="com.foo.AnotherBean"/>
这样当一个bean需要使用到这个bean的时候才会初始化这个bean
模式 | 说明 |
no | 不使用自动装配。必须通过ref元素指定依赖,这是默认设置。由于显式指定协作者可以使配置更灵活、更清晰,因此对于较大的部署配置,推荐采用该设置。而且在某种程度上,它也是系统架构的一种文档形式。 |
byName | 根据属性名自动装配。此选项将检查容器并根据名字查找与属性完全一致的bean,并将其与属性自动装配。例如,在bean定义中将autowire设置为by name,而该bean包含master属性(同时提供setMaster(..)方法),Spring就会查找名为master的bean定义,并用它来装配给master属性。 |
byType | 如果容器中存在一个与指定属性类型相同的bean,那么将与该属性自动装配。如果存在多个该类型的bean,那么将会抛出异常,并指出不能使用byType方式进行自动装配。若没有找到相匹配的bean,则什么事都不发生,属性也不会被设置。如果你不希望这样,那么可以通过设置dependency-check="objects"让Spring抛出异常。 |
constructor | 与byType的方式类似,不同之处在于它应用于构造器参数。如果在容器中没有找到与构造器参数类型一致的bean,那么将会抛出异常。 |
autodetect | 通过bean类的自省机制(introspection)来决定是使用constructor还是byType方式进行自动装配。如果发现默认的构造器,那么将使用byType方式。 |
引用开发手册原文:
理解自动装配的优缺点是很重要的。其中优点包括:
· 自动装配能显著减少配置的数量。不过,采用bean模板(见这里)也可以达到同样的目的。
· 自动装配可以使配置与java代码同步更新。例如,如果你需要给一个java类增加一个依赖,那么该依赖将被自动实现而不需要修改配置。因此强烈推荐在开发过程中采用自动装配,而在系统趋于稳定的时候改为显式装配的方式。
自动装配的一些缺点:
· 尽管自动装配比显式装配更神奇,但是,正如上面所提到的,Spring会尽量避免在装配不明确的时候进行猜测,因为装配不明确可能出现难以预料的结果,而且Spring所管理的对象之间的关联关系也不再能清晰的进行文档化。
· 对于那些根据Spring配置文件生成文档的工具来说,自动装配将会使这些工具没法生成依赖信息。
· 如果采用by type方式自动装配,那么容器中类型与自动装配bean的属性或者构造函数参数类型一致的bean只能有一个,如果配置可能存在多个这样的bean,那么就要考虑采用显式装配了。
尽管使用autowire没有对错之分,但是能在一个项目中保持一定程度的一致性是最好的做法。例如,通常情况下如果没有使用自动装配,那么仅自动装配一个或两个bean定义可能会引起开发者的混淆。
3.4. bean的作用域
3.4.1. Singleton作用域
当把一个bean定义设置为singlton作用域时,Spring IoC容器只会创建该bean定义的唯一实例。这个单一实例会被存储到单例缓存(singleton cache)中,并且所有针对该bean的后续请求和引用都将返回被缓存的对象实例。
<bean id="accountService" class="com.foo.DefaultAccountService" scope="singleton"/>
<bean id="accountService" class="com.foo.DefaultAccountService" singleton="true"/>
Prototype作用域的bean会导致在每次对该bean请求(将其注入到另一个bean中,或者以程序的方式调用容器的getBean()方法)时都会创建一个新的bean实例。根据经验,对所有有状态的bean应该使用prototype作用域,而对无状态的bean则应该使用singleton作用域。
<bean id="accountService" class="com.foo.DefaultAccountService" scope="prototype"/>
简单地说,如果你用"singleton"属性那么就必须在那个文件里引用'spring-beans.dtd' DTD。 如果你用"scope"属性那么必须 在那个文件里引用'spring-beans-2.0.dtd' DTD 或'spring-beans-2.0.xsd' XSD。
今天就看到这里,也许在将来的几天中我会将这个学习笔记作为我的工作日志,里面会写上一些关于Hibernate的学习笔记
<bean id="loginAction" class="com.foo.LoginAction" scope="request"/>
针对每次HTTP请求,Spring容器会根据loginAction bean定义创建一个全新的LoginAction bean实例,且该loginAction bean实例仅在当前HTTP request内有效,因此可以根据需要放心的更改所建实例的内部状态,而其他请求中根据loginAction bean定义创建的实例,将不会看到这些特定于某个请求的状态变化。当处理请求结束,request作用域的bean实例将被销毁。
<bean id="userPreferences" class="com.foo.UserPreferences" scope="session"/>
针对某个HTTP Session,Spring容器会根据userPreferences bean定义创建一个全新的userPreferences bean实例,且该userPreferences bean仅在当前HTTP Session内有效。与request作用域一样,你可以根据需要放心的更改所创建实例的内部状态,而别的HTTP Session中根据userPreferences创建的实例,将不会看到这些特定于某个HTTP Session的状态变化。当HTTP Session最终被废弃的时候,在该HTTP Session作用域内的bean也会被废弃掉。
<bean id="userPreferences" class="com.foo.UserPreferences" scope="session">
<aop:scoped-proxy/>
</bean>
<bean id="userManager" class="com.foo.UserManager">
<property name="userPreferences" ref="userPreferences"/>
</bean>
当注入某种类型对象时,该对象实现了和UserPreferences类一样的公共接口(即UserPreferences实例)。并且不论我们底层选择了何种作用域机制(HTTP request、Session等等),容器都会足够智能的获取到真正的UserPreferences对象,因此我们需要将该对象的代理注入到userManager bean中, 而userManager bean并不会意识到它所持有的是一个指向UserPreferences引用的代理。在本例中,当UserManager实例调用了一个使用UserPreferences对象的方法时,实际调用的是代理对象的方法。随后代理对象会从HTTP Session获取真正的UserPreferences对象,并将方法调用委派给获取到的实际的UserPreferences对象。