Spring 学习笔记Spring 学习笔记

引用：使用index属性除了可以解决多个简单类型构造参数造成的模棱两可的问题之外，还可以用来解决两个构造参数类型相同造成的麻烦。注意：index属性值从0开始。

在上面的例子中，<code>child</code>bean的<code>adminEmails</code>属性的<code>&lt;props/&gt;</code>元素上使用了<code>merge=true</code>属性。当<code>child </code>bean被容器实际解析及实例化时，其 <code>adminEmails</code>将与父集合的<code>adminEmails</code>属性进行合并。

上述的配置等同于Java代码：<code>exampleBean.setEmail(null)</code>。

等同于：

当设置bean的组合属性时，除了最后一个属性外，只要其他属性值不为null，组合或嵌套属性名是完全合法的。例如，下面bean的定义：

<code>foo</code> bean有个<code>fred</code>属性，此属性有个 <code>bob</code>属性，而<code>bob</code>属性又有个<code>sammy</code>属性，最后把<code>sammy</code>属性设置为<code>123</code>。为了让此定义能工作， <code>foo</code>的<code>fred</code>属性及<code>fred</code> 的<code>bob</code>属性在bean被构造后都必须非空，否则将抛出<code>NullPointerException</code>异常。

若需要表达对多个bean的依赖，可以在<code>'depends-on'</code>中将指定的多个bean名字用分隔符进行分隔，分隔符可以是逗号、空格及分号等。下面的例子中使用了<code>'depends-on'</code>来表达对多个bean的依赖。

<code>ApplicationContext</code>实现的默认行为就是在启动时将所有<code>singleton</code> bean提前进行实例化。提前实例化意味着作为初始化过程的一部分，<code>ApplicationContext</code>实例会创建并配置所有的singleton bean。通常情况下这是件好事，因为这样在配置中的任何错误就会即刻被发现（否则的话可能要花几个小时甚至几天）。

有时候这种默认处理可能并不是你想要的。如果你不想让一个singleton bean在<code>ApplicationContext</code>实现在初始化时被提前实例化，那么可以将bean设置为延迟实例化。一个延迟初始化bean将告诉IoC 容器是在启动时还是在第一次被用到时实例化。

在XML配置文件中，延迟初始化将通过<code>&lt;bean/&gt;</code>元素中的<code>lazy-init</code>属性来进行控制。

模式

说明

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方式。

理解自动装配的优缺点是很重要的。其中优点包括：

·         自动装配可以使配置与java代码同步更新。例如，如果你需要给一个java类增加一个依赖，那么该依赖将被自动实现而不需要修改配置。因此强烈推荐在开发过程中采用自动装配，而在系统趋于稳定的时候改为显式装配的方式。

自动装配的一些缺点：

·         尽管自动装配比显式装配更神奇，但是，正如上面所提到的，Spring会尽量避免在装配不明确的时候进行猜测，因为装配不明确可能出现难以预料的结果，而且Spring所管理的对象之间的关联关系也不再能清晰的进行文档化。

·         对于那些根据Spring配置文件生成文档的工具来说，自动装配将会使这些工具没法生成依赖信息。

·         如果采用by type方式自动装配，那么容器中类型与自动装配bean的属性或者构造函数参数类型一致的bean只能有一个，如果配置可能存在多个这样的bean，那么就要考虑采用显式装配了。

尽管使用autowire没有对错之分，但是能在一个项目中保持一定程度的一致性是最好的做法。例如，通常情况下如果没有使用自动装配，那么仅自动装配一个或两个bean定义可能会引起开发者的混淆。

&lt;bean id="accountService" class="com.foo.DefaultAccountService" scope="singleton"/&gt;

&lt;bean id="accountService" class="com.foo.DefaultAccountService" singleton="true"/&gt;

Prototype作用域的bean会导致在每次对该bean请求（将其注入到另一个bean中，或者以程序的方式调用容器的<code>getBean()</code>方法）时都会创建一个新的bean实例。根据经验，对所有有状态的bean应该使用prototype作用域，而对无状态的bean则应该使用singleton作用域。

简单地说，如果你用"<code>singleton</code>"属性那么就必须在那个文件里引用<code>'spring-beans.dtd'</code> DTD。 如果你用"<code>scope</code>"属性那么必须 在那个文件里引用<code>'spring-beans-2.0.dtd'</code> DTD 或<code>'spring-beans-2.0.xsd'</code> XSD。

针对每次HTTP请求，Spring容器会根据<code>loginAction</code> bean定义创建一个全新的<code>LoginAction</code> bean实例，且该<code>loginAction</code> bean实例仅在当前HTTP request内有效，因此可以根据需要放心的更改所建实例的内部状态，而其他请求中根据<code>loginAction</code> bean定义创建的实例，将不会看到这些特定于某个请求的状态变化。当处理请求结束，request作用域的bean实例将被销毁。

针对某个HTTP <code>Session</code>，Spring容器会根据<code>userPreferences</code> bean定义创建一个全新的<code>userPreferences</code> bean实例，且该<code>userPreferences</code> bean仅在当前HTTP <code>Session</code>内有效。与<code>request作用域</code>一样，你可以根据需要放心的更改所创建实例的内部状态，而别的HTTP <code>Session</code>中根据<code>userPreferences</code>创建的实例，将不会看到这些特定于某个HTTP <code>Session</code>的状态变化。当HTTP <code>Session</code>最终被废弃的时候，在该HTTP <code>Session</code>作用域内的bean也会被废弃掉。

今天下午写了一个基于SpringMVC的架构，内部包含JSTL，明天会加上displaytag，今天又遇到了“监听器异常”的问题，经过 检查发现我的jdbc.properties文件用的classpath，问题解决，还遇到了两个字母敲错了的错误，解决，明天的任务是使用 displaytag把数据库的数据取出来导出为各种格式的（pdf、excel）

（我们一般只用他的跳转功能）类的方法，

Method Summary

          Return the name of the view to delegate to.

          Return a ModelAndView object with the specified view name.

<code>protected  void</code>

          Subclasses can override this for custom initialization behavior.

<code> void</code>

          Set the name of the view to delegate to.

子类可以继承并实现initApplicationContext这个方法，用于初始化一些属性

本文转自yunlielai51CTO博客，原文链接：http://blog.51cto.com/4925054/1060111，如需转载请自行联系原作者