细谈Spring(一)spring简介
Spring 是一个开源框架,是为了解决企业应用程序开发复杂性而创建的。框架的主要优势之一就是其分层架构,分层架构允许您选择使用哪一个组件,同时为 J2EE 应用程序开发提供集成的框架。 然而,Spring的用途不仅限于服务器端的开发。从简单性、可测试性和松耦合的角度而言,任何Java应用都可以从Spring中受益。 Spring的核心是个轻量级容器(container),实现了IoC(Inversion of Control)模式的容器,Spring的目标是实现一个全方位的整合框架,在Spring框架下实现多个子框架的组合,这些子框架之间彼此可以独立,也可以使用其它的框架方案加以替代,Spring希望提供one-stop shop的框架整合方案
简单来说,Spring是一个轻量级的控制反转(IOC)和面向切面(AOP)的容器框架。
轻量——从大小与开销两方面而言Spring都是轻量的。完整的Spring框架可以在一个大小只有1MB多的JAR文件里发布。并且Spring所需的处理开销也是微不足道的。此外,Spring是非侵入式的:典型地,Spring应用中的对象不依赖于Spring的特定类。
控制反转——Spring通过一种称作控制反转(IoC)的技术促进了松耦合。当应用了IoC,一个对象依赖的其它对象会通过被动的方式传递进来,而不是这个对象自己创建或者查找依赖对象。你可以认为IoC与JNDI相反——不是对象从容器中查找依赖,而是容器在对象初始化时不等对象请求就主动将依赖传递给它。
面向切面——Spring提供了面向切面编程的丰富支持,允许通过分离应用的业务逻辑与系统级服务(例如审计(auditing)和事务(transaction)管理)进行内聚性的开发。应用对象只实现它们应该做的——完成业务逻辑——仅此而已。它们并不负责(甚至是意识)其它的系统级关注点,例如日志或事务支持。
容器——Spring包含并管理应用对象的配置和生命周期,在这个意义上它是一种容器,你可以配置你的每个bean如何被创建——基于一个可配置原型(prototype),你的bean可以创建一个单独的实例或者每次需要时都生成一个新的实例——以及它们是如何相互关联的。然而,Spring不应该被混同于传统的重量级的EJB容器,它们经常是庞大与笨重的,难以使用。
框架——Spring可以将简单的组件配置、组合成为复杂的应用。在Spring中,应用对象被声明式地组合,典型地是在一个XML文件里。Spring也提供了很多基础功能(事务管理、持久化框架集成等等),将应用逻辑的开发留给了你。 所有Spring的这些特征使你能够编写更干净、更可管理、并且更易于测试的代码。它们也为Spring中的各种模块提供了基础支持。
Spring 框架是一个分层架构,由 7 个定义良好的模块组成。Spring 模块构建在核心容器之上,核心容器定义了创建、配置和管理 bean 的方式,如下图所示:
Spring 框架的分为7个模块,组成 Spring 框架的每个模块(或组件)都可以单独存在,或者与其他一个或多个模块联合实现。每个模块的功能如下:
1.核心容器:核心容器提供 Spring 框架的基本功能。核心容器的主要组件是 BeanFactory,它是工厂模式的实现。BeanFactory 使用控制反转 (IOC) 模式将应用程序的配置和依赖性规范与实际的应用程序代码分开。
2.Spring 上下文:Spring 上下文是一个配置文件,向 Spring 框架提上下文信息。Spring 上下文包括企业服务,例如 JNDI、EJB、电子邮件、国际化、校验和调度功能。
3.Spring AOP:通过配置管理特性,Spring AOP 模块直接将面向方面的编程功能集成到了 Spring 框架中。所以,可以很容易地使 Spring 框架管理的任何对象支持 AOP。Spring AOP 模块为基于 Spring 的应用程序中的对象提供了事务管理服务。通过使用 Spring AOP,不用依赖 EJB 组件,就可以将声明性事务管理集成到应用程序中。
4. Spring DAO:JDBC DAO 抽象层提供了有意义的异常层次结构,可用该结构来管理异常处理和不同数据库供应商抛出的错误消息。异常层次结构简化了错误处理,并且极大地降低了需要编写的异常代码数量(例如打开和关闭连接)。Spring DAO 的面向 JDBC 的异常遵从通用的 DAO 异常层次结构。
5.Spring ORM:Spring 框架插入了若干个 ORM 框架,从而提供了 ORM 的对象关系工具,其中包括 JDO、Hibernate 和 iBatis SQL Map。所有这些都遵从 Spring 的通用事务和 DAO 异常层次结构。
6. Spring Web 模块:Web 上下文模块建立在应用程序上下文模块之上,为基于 Web 的应用程序提供了上下文。所以,Spring 框架支持与 Jakarta Struts 的集成。Web 模块还简化了处理多部分请求以及将请求参数绑定到域对象的工作。
7. Spring MVC 框架:MVC 框架是一个全功能的构建 Web 应用程序的 MVC 实现。通过策略接口,MVC 框架变成为高度可配置的,MVC 容纳了大量视图技术,其中包括 JSP、Velocity、Tiles、iText 和 POI。
Spring 框架的功能可以用在任何 J2EE 服务器中,大多数功能也适用于不受管理的环境。Spring 的核心要点是:支持不绑定到特定 J2EE 服务的可重用业务和数据访问对象。毫无疑问,这样的对象可以在不同 J2EE 环境 (Web 或 EJB)、独立应用程序、测试环境之间重用。
总结起来,Spring有如下优点:
1.低侵入式设计,代码污染极低
2. 独立于各种应用服务器,可以真正实现Write Once,Run Anywhere的承诺
3.Spring的DI机制降低了业务对象替换的复杂性
4.Spring并不完全依赖于Spring,开发者可自由选用Spring框架的部分或全部
IOC 和 AOP:这两个概念可以算是spring中的核心了,这两个概念非常抽象,并且也不容易理解,所以我们下面来简单来描述一下这两个概念。
控制反转模式(也称作依赖性介入)的基本概念是:不创建对象,但是描述创建它们的方式。在代码中不直接与对象和服务连接,但在配置文件中描述哪一个组件需要哪一项服务。容器 (在 Spring 框架中是 IOC 容器) 负责将这些联系在一起。在典型的 IOC 场景中,容器创建了所有对象,并设置必要的属性将它们连接在一起,决定什么时间调用方法。下表列出了 IOC 的一个实现模式。
类型 1 | 服务需要实现专门的接口,通过接口,由对象提供这些服务,可以从对象查询依赖性(例如,需要的附加服务),这种用的很少 |
类型 2 | 通过 JavaBean 的属性(例如 setter 方法)分配依赖性 |
类型 3 | 依赖性以构造函数的形式提供,不以 JavaBean 属性的形式公开 |
Spring 框架的 IOC 容器主要采用类型 2 和类型3 实现。
面向方面的编程,即 AOP,是一种编程技术,它允许程序员对横切关注点或横切典型的职责分界线的行为(例如日志和事务管理)进行模块化。AOP 的核心构造是方面,它将那些影响多个类的行为封装到可重用的模块中。
AOP 和 IOC 是补充性的技术,它们都运用模块化方式解决企业应用程序开发中的复杂问题。在典型的面向对象开发方式中,可能要将日志记录语句放在所有方法和 Java 类中才能实现日志功能。在 AOP 方式中,可以反过来将日志服务模块化,并以声明的方式将它们应用到需要日志的组件上。当然,优势就是 Java 类不需要知道日志服务的存在,也不需要考虑相关的代码。所以,用 Spring AOP 编写的应用程序代码是松散耦合的。AOP 的功能完全集成到了 Spring 事务管理、日志和其他各种特性的上下文中。
IOC 容器:Spring 设计的核心是 org.springframework.beans 包,它的设计目标是与 JavaBean 组件一起使用。这个包通常不是由用户直接使用,而是由服务器将其用作其他多数功能的底层中介。下一个最高级抽象是 BeanFactory 接口,它是工厂设计模式的实现,允许通过名称创建和检索对象。BeanFactory 也可以管理对象之间的关系。
BeanFactory 支持两个对象模型:
1.单态 模型提供了具有特定名称的对象的共享实例,可以在查询时对其进行检索。Singleton 是默认的也是最常用的对象模型。对于无状态服务对象很理想。
2. 原型 模型确保每次检索都会创建单独的对象。在每个用户都需要自己的对象时,原型模型最适合。
bean 工厂的概念是 Spring 作为 IOC 容器的基础。IOC 将处理事情的责任从应用程序代码转移到框架。正如我将在下一个示例中演示的那样,Spring 框架使用 JavaBean 属性和配置数据来指出必须设置的依赖关系。
Spring的源码设计精妙、结构清晰、匠心独用,处处体现着大师对java设计模式灵活运用以及对Java技术的高深造诣。Spring框架源码无疑是Java技术的最佳实践范例。如果想在短时间内迅速提高自己的Java技术水平和应用开发水平,学习和研究Spring源码将会使你收到意想不到的效果。 可是从哪着手研究Spring却是很多新手头疼的地方,下面的参考资料将带领大家慢慢的深入解析Spring
2 ioc容器在Web容器中的启动
3 Spring JDBC
4 Spring MVC
5 Spring AOP获取Proxy
6 Spring声明式事务处理
7 Spring AOP中对拦截器调用的实现
8 Spring驱动Hibernate的实现
9 Spring Acegi框架鉴权的实现
具体的源码解析内容大家可以百度或者谷歌一下,可以找到大量源码解析内容。
细谈Spring(二)自己动手模拟spring
在我们学习spring之前,根据spring的特性,我们来自己来模拟一个spring出来,也就是说不利用spring来实现spring的效果。本实例主要是实现spring的IOC功能。
点击下载源码:用力点
首先我们把我们用的dao、service、entity定义出来:
Student.java :
因为spring提倡的就是面向接口编程,所以在我们写dao层和service层具体实现之前,我们先定义接口,让我们的具体实现实现接口。接口的代码很简单,在这就不贴出来了。
StudentServiceImp.java
这里要注意的是,我们这里是模拟spring,主要模拟spring中的IOC功能,所以在此我们一样要在service层中定义dao的实例,当然不用new出来,我们就通过spring的IOC把这里的dao层注入进来。不要忘了对dao提供set。Get方法,因为IOC的底层其实就是利用反射机制实现的,他把dao注入进来,其实底层就是通过反射set进来的。
好了,我们所需的dao层、service层还有entity定义好了之后,万事俱备只欠东风了,下一步我们就是定义我们自己的ClassPathXmlApplicationContext类了,通过他,在我们new出他的对象的时候,他来加载配置文件,然后把我们的dao操作注入到我们的service层,在spring中,ClassPathXmlApplicationContext类实现了BeanFactory接口,在此我们也定义一个BeanFactory接口,其实这个接口没什么具体的作用,我们就是为了来模拟spring。在定义这个接口和实现类之前,我们先来看一下我们所需的xml是怎么编写的,下面我们就具体来看一下beans.xml的配置:
Beans.xml:
看到这,相信大家都能感觉到这个配置文件太简单了,没有spring中那么多繁琐的配置,当然啦,我们这是只是实现其中的一个功能,spring提供了很多那么强大的功能,配置当然繁琐一些了。相信上边的代码不用我解释大家也能看懂了吧。
好了,配置文件我们看完了,下一步我们一起来看一下我们的spring容器——ClassPathXmlApplicationContext具体是怎么实现的,我们首先还是来看一下他的接口定义:
BeanFactory.java:
我们看到,接口其实很简单,就定义了一个getBean方法,下面我们来看一下具体的实现类:
ClassPathXmlApplicationContext.java
代码贴出来了,不知道大家看懂没有。下面我来解释一下这段代码:
首先我们定义了一个容器Map<String, Object> beans,这个容器的作用就是用来装我们从配置文件里解析来的一个个bean,为什么要用map类型,我想大家也差不多能猜到吧,我们配置文件中每一个bean都有一个id来作为自己的唯一身份。我们把这个id存到map的key里面,然后value就装我们的具体bean对象。说完这个容器之后,下面我们在来看一下ClassPathXmlApplicationContext的构造方法,这个构造方法是我们spring管理容器的核心,这个构造方法的前半部分是利用的jdom解析方式,把xml里面的bean一个个的解析出来,然后把解析出来的bean在放到我们bean容器里。如果这段代码看不懂的话,那你只好在去看看jdom解析xml了。好了,我们下面在来看一下这个构造的方法,后半部分主要是在对配置文件进行解析出bean的同时去查看一下这个bean中有没有需要注射bean的,如果有的话,他就去通过这些里面的property属性获取他要注射的bean名字,然后构造出set方法,然后通过反射,调用注入bean的set方法,这样我们所需要的bean就被注入进来了。如果这段代码你看不懂的话,那你只能去看一下有关反射的知识了。最后我们就来看一下实现接口的getBean放了,其实这个方法很简单,就是根据提供的bean的id,从bean容器内把对应的bean取出来。
好了,我们所需的东西都定义好了,下面我们据来测试一下,看看我们自己模仿的spring到底能不能自动把我们所需要的dao层给我们注入进来。
运行代码,控制台输出:
com.bzu.service.imp.StudentServiceImp
method name = setStuDao
stu is saved
好,成功注入进来,到此,我们模仿的spring就到此结束了.
细谈Spring(三)IOC和spring基本配置详解
对于IoC 的一些知识点,相信大家都知道他在Spring框架中所占有的地位,应该可以算的上是核心之一吧,所以IOC是否理解清楚,决定了大家对Spring整个框架的理解
Ioc的理解
spring 的两个核心概念:一个是控制反转IoC,也可以叫做依赖注入DI。还有一个是面向切面编程AOP。
控制反转:当某个java 对象需要(依赖)另一个java 对象时,不
是自身直接创建依赖对象,而是由实现IoC 的容器(如spring 框架的IoC容器)来创建,并将它注入需要这个依赖对象的java 对象中。
spring 的容器
spring 管理的基本单元是Bean,在spring 的应用中,所有的组件都是一个个的Bean,它可以是任何的java 对象。spring 负责创建这些Bean的实例。并管理生命周期。而spring 框架是通过其内置的容器来完成Bean 的管理的,Bean 在spring 的容器中生存着,使用时只需要通过它提供的一些方法从其中获取即可。
spring 的容器有两个接口:BeanFactory 和ApplicationContext 这两个接口的实例被陈为spring 的上下文。
注:由于ApplicationContext是基于BeanFactory之上的,所以,一般ApplicationContext功能比较强大,建议使用
ApplicationContext经常用到的三个实现:
1.ClassPathXmlApplicationContext:从类路径中的XML文件载入上下文定义信息。把上下文定义文件当成类路径资源。
2.FileSystemXmlApplicationContext:从文件系统中的XML文件载入上下文定义信息。
3.XmlWebApplicationContext:从Web系统中的XML文件载入上下文定义信息。
一:spring 的依赖注入
1)、构造器注入
注:这种注入方式很少用,如果是注入对象一般为上例注入,但有时要注入基本数据类型,一般用下面方法注入
如果构造方法不只一个参数时,应指明所注入参数的索引或者数据类型,例如:
2)、设值(set 方法)注入
注:<property name="accountDaoImpl" ref="accoutDaoImpl"/>
相当于调用set AccountDaoImpl方法,把值设为accoutDaoImpl
3)接口注入(很少用)
二: xml 装配Bean属性含义
1.id:指定该Bean 的唯一标识。
2.class:指定该Bean 的全限定名。
3.name:为该Bean 指定一到多个别名。多个别名可以用“,”和“;”分割。
4.autowire:指定该Bean 的属性的装配方式。
所谓自动装配是指在<BEAN>标签中不用指定其依赖的BEAN,而是通过配置的自动装配来自动注入依赖的BEAN,这种做法让我们的配置更加简单
1)no:不使用自动装配。必须通过ref 元素指定依赖,这是默认设置。由于显式指定协作者可以使配置更灵活、更清晰,因此对于较大的部署配置,推荐采用该设置。而且在某种程度上,它也是系统架构的一种文档形式。
备注:有property 属性指定ref
2)byName:根据属性名自动装配。此选项将检查容器并根据
名字查找与属性完全一致的bean,并将其与属性自动装配。例如,在
bean 定义中将autowire 设置为by name,而该bean 包含master 属性(同时提供setMaster(..)方法),Spring 就会查找名为master 的bean 定义,并用它来装配给master 属性。
<bean id="bean1" class="cn.csdn.service.Bean1"
scope="singleton" autowire="byName"/>
备注:没有property 属性
3)byType:如果容器中存在一个与指定属性类型相同的
bean,那么将与该属性自动装配。如果存在多个该类型的bean,那么
将会抛出异常,并指出不能使用byType 方式进行自动装配。若没有找到相匹配的bean,则什么事都不发生,属性也不会被设置。如果你不希望这样,那么可以通过设置dependency-check="objects"让Spring 抛出异常。
备注:spring3.0 以上不抛异常。
<bean id="bean1" class="cn.csdn.service.Bean1"
scope="singleton" autowire="byType"/>
备注:没有property 属性
4)Constructor:与byType 的方式类似,不同之处在于它应用
于构造器参数。如果在容器中没有找到与构造器参数类型一致的bean,那么将会抛出异常。
<bean id="bean1" class="cn.csdn.service.Bean1"
scope="singleton"autowire="constructor"/>
备注:没有property 属性
5)autodetect:通过bean 类的自省机制(introspection)来决定是使用constructor 还是byType 方式进行自动装配。如果发现默认的
构造器,那么将使用byType 方式。
<bean id="bean1" class="cn.csdn.service.Bean1"
scope="singleton" autowire="autodetect"/>
5.scope:指定该Bean 的生存范围
scope用来声明IOC容器中的对象应该处的限定场景或者说该对象的存活空间,即在IOC容器在对象进入相应的scope之前,生成并装配这些对象,在该对象不再处于这些scope的限定之后,容器通常会销毁这些对象。
1) singleton类型的bean定义,在一个容器中只存在一个实例,所有对该类型bean的依赖都引用这一单一实例
2) scope为prototype的bean,容器在接受到该类型的对象的请求的时候,会每次都重新生成一 个新的对象给请求方,虽然这种类型的对象的实例化以及属性设置等工作都是由容器负责的,但是只要准备完毕,并且对象实例返回给请求方之后,容器就不在拥有 当前对象的引用,请求方需要自己负责当前对象后继生命周期的管理工作,包括该对象的销毁
3) request ,session和global session
这三个类型是spring2.0之后新增的,他们只适用于web程序,通常是和XmlWebApplicationContext共同使用
request:
<bean id ="requestPrecessor" class="...RequestPrecessor" scope="request" />
Spring容器,即XmlWebApplicationContext 会为每个HTTP请求创建一个全新的RequestPrecessor对象,当请求结束后,,该对象的生命周期即告结束
session
<bean id ="userPreferences" class="...UserPreferences" scope="session" />
Spring容器会为每个独立的session创建属于自己的全新的UserPreferences实例,他比request scope的bean会存活更长的时间,其他的方面真是没什么区别。
global session:
<bean id ="userPreferences" class="...UserPreferences" scope="globalsession" />
global session只有应用在基于porlet的web应用程序中才有意义,他映射到porlet的global范围的session,如果普通的servlet的web 应用中使用了这个scope,容器会把它作为普通的session的scope对待。
6.init-method:指定该Bean 的初始化方法。destroy-method:指定该Bean 的销毁方法。这个就像servlet中init和destroy方法一样,只不过这里在配置文件配置的
7.abstract:指定该Bean 是否为抽象的。如果是抽象的,则
spring 不为它创建实例。
8.parent
如果两个Bean 的属性装配信息很相似,那么可以利用继
承来减少重复的配置工作。
<!-- 装配Bean 的继承
父类作为模板,不需要实例化,设置abstract=”true”-->
` <bean id=”parent” class=”cn.csdn.service.Parent”
abstract=”true”>
<property name=”name” value=”z_xiaofei168”/>
<property name=”pass” value=”z_xiaofei168”/>
</bean>
<!-- 装配Bean 的继承
子类中用parent 属性指定父类标识或别名
子类可以覆盖父类的属性装配,也可以新增自己的属性装配
-->
` <bean id=”child” class=”cn.csdn.service.Chlid”
parent=”parent”>
<property name=”pass” value=”123123”/>
<property name=”age” value=”22”/>
</bean>
三:装配Bean 的各种类型属性值
1..简单类型属性值的装配
2.引用其他Bean 的装配
另外一种不常使用的配置方式是在property 元素中嵌入
一个bean 元素来指定所引用的Bean.
3.集合的装配
其实集合的装配并不是复杂,反而感觉到很简单,用一个例子来说明问题吧:
配置如下:
四:Spring bean生命周期
在传统的Java应用中,Bean的生命周期非常简单。 Java的关键词new用来实例化Bean(或许他是非序列化的)。这样就够用了。 相反,Bean的生命周期在Spring容器中更加细致。 理解Spring Bean的生命周期非常重要,因为你或许要利用Spring提供的机会来订制Bean的创建过程。
bean生命周期
1.容器寻找Bean的定义信息并且将其实例化。
2.受用依赖注入,Spring按照Bean定义信息配置Bean的所有属性。
3.如果Bean实现了BeanNameAware接口,工厂调用Bean的setBeanName()方法传递Bean的ID。
4.如果Bean实现了BeanFactoryAware接口,工厂调用setBeanFactory()方法传入工厂自身。
5.如果BeanPostProcessor和Bean关联,那么它们的postProcessBeforeInitialzation()方法将被调用。
6.如果Bean指定了init-method方法,它将被调用。
7.最后,如果有BeanPsotProcessor和Bean关联,那么它们的postProcessAfterInitialization()方法将被调用。
到这个时候,Bean已经可以被应用系统使用了,并且将被保留在Bean Factory中知道它不再需要。
有两种方法可以把它从Bean Factory中删除掉。
1.如果Bean实现了DisposableBean接口,destory()方法被调用。
2.如果指定了订制的销毁方法,就调用这个方法。
Bean在Spring应用上下文的生命周期与在Bean工厂中的生命周期只有一点不同, 唯一不同的是,如果Bean实现了ApplicationContextAwre接口,setApplicationContext()方法被调用。
只有singleton行为的bean接受容器管理生命周期。
non-singleton行为的bean,Spring容器仅仅是new的替代,容器只负责创建。
对于singleton bean,Spring容器知道bean何时实例化结束,何时销毁, Spring可以管理实例化结束之后,和销毁之前的行为,管理bean的生命周期行为主要未如下两个时机:
Bean全部依赖注入之后
Bean即将销毁之前
1)依赖关系注入后的行为实现:
有两种方法:A.编写init方法 B.实现InitializingBean接口
afterPropertiesSet和init同时出现,前者先于后者执行,使用init方法,需要对配置文件加入init-method属性
2)bean销毁之前的行为
有两种方法:A.编写close方法 B.实现DisposableBean接口
destroy和close同时出现,前者先于后者执行,使用close方法,需要对配置文件加入destroy-method属性
总体上分只为四个阶段
1. BeanFactoyPostProcessor实例化
2. Bean实例化,然后通过某些BeanFactoyPostProcessor来进行依赖注入
3. BeanPostProcessor的调用.Spring内置的BeanPostProcessor负责调用Bean实现的接口: BeanNameAware, BeanFactoryAware, ApplicationContextAware等等,等这些内置的BeanPostProcessor调用完后才会调用自己配置的BeanPostProcessor
4.Bean销毁阶段
注:xml依赖注入中的bean.xml例子:
细谈Spring(四)利用注解实现spring基本配置详解
1.准备工作
(1)导入common-annotations.jar
(2)导入schema文件 文件名为spring-context-2.5.xsd
(3)在xml的beans节点中配置
2.xml配置工作
注:<context:component-scan base-package="*.*" />
该配置隐式注册了多个对注解进行解析的处理器,如:
AutowiredAnnotationBeanPostProcessor
CommonAnnotationBeanPostProcessor
PersistenceAnnotationBeanPostProcessor
RequiredAnnotationBeanPostProcessor
其实,注解本身做不了任何事情,和XML一样,只起到配置的作用,主要在于背后强大的处理器,其中就包括了<context:annotation-config/>配置项里面的注解所使用的处理器,所以配置了<context:component-scanbase-package="">之后,便无需再配置<context:annotation-config>
1.在java代码中使用@Autowired或@Resource注解方式进行装配 ,这两个注解的区别是:@Autowired默认按类型装配,@Resource默认按名称装配,当找不到名称匹配的bean才会按类型装配。
@Autowired一般装配在set方法之上,也可以装配在属性上边,但是在属性上边配置,破坏了java的封装,所以一般不建议使用
@Autowired是根据类型进行自动装配的。如果当Spring上下文中存在不止一个所要装配类型的bean时,就会抛出BeanCreationException异常;如果Spring上下文中不存在所要装配类型的bean,也会抛出BeanCreationException异常。我们可以使用@Qualifier配合@Autowired来解决这些问题。
这样,Spring会找到id为userDao的bean进行装配。
可能不存在UserDao实例
2.@Resource(JSR-250标准注解,推荐使用它来代替Spring专有的@Autowired注解)Spring 不但支持自己定义的@Autowired注解,还支持几个由JSR-250规范定义的注解,它们分别是@Resource、@PostConstruct以及@PreDestroy。
@Resource的作用相当于@Autowired,只不过@Autowired按byType自动注入,而@Resource默认按byName自动注入罢了。@Resource有两个属性是比较重要的,分别是name和type,Spring将@Resource注解的name属性解析为bean的名字,而type属性则解析为bean的类型。所以如果使用name属性,则使用byName的自动注入策略,而使用type属性时则使用byType自动注入策略。如果既不指定name也不指定type属性,这时将通过反射机制使用byName自动注入策略
@Resource装配顺序
1 如果同时指定了name和type,则从Spring上下文中找到唯一匹配的bean进行装配,找不到则抛出异常
2 如果指定了name,则从上下文中查找名称(id)匹配的bean进行装配,找不到则抛出异常
3 如果指定了type,则从上下文中找到类型匹配的唯一bean进行装配,找不到或者找到多个,都会抛出异常
4 如果既没有指定name,又没有指定type,则自动按照byName方式进行装配(见2);如果没有匹配,则回退为一个原始类型(UserDao)进行匹配,如果匹配则自动装配;
3. @PostConstruct(JSR-250)
在方法上加上注解@PostConstruct,这个方法就会在Bean初始化之后被Spring容器执行(注:Bean初始化包括,实例化Bean,并装配Bean的属性(依赖注入))。
它的一个典型的应用场景是,当你需要往Bean里注入一个其父类中定义的属性,而你又无法复写父类的属性或属性的setter方法时,如:
这里通过@PostConstruct,为UserDaoImpl的父类里定义的一个sessionFactory私有属性,注入了我们自己定义的sessionFactory(父类的setSessionFactory方法为final,不可复写),之后我们就可以通过调用super.getSessionFactory()来访问该属性了。
4.@PreDestroy(JSR-250)
在方法上加上注解@PreDestroy,这个方法就会在Bean初始化之后被Spring容器执行。由于我们当前还没有需要用到它的场景,这里不不去演示。其用法同@PostConstruct。
5.使用Spring注解完成Bean的定义
以上我们介绍了通过@Autowired或@Resource来实现在Bean中自动注入的功能,下面我们将介绍如何注解Bean,从而从XML配置文件中完全移除Bean定义的配置。
@Component:只需要在对应的类上加上一个@Component注解,就将该类定义为一个Bean了:
使用@Component注解定义的Bean,默认的名称(id)是小写开头的非限定类名。如这里定义的Bean名称就是userDaoImpl。你也可以指定Bean的名称:
@Component("userDao")
@Component是所有受Spring管理组件的通用形式,Spring还提供了更加细化的注解形式:@Repository、@Service、@Controller,它们分别对应存储层Bean,业务层Bean,和展示层Bean。目前版本(2.5)中,这些注解与@Component的语义是一样的,完全通用,在Spring以后的版本中可能会给它们追加更多的语义。所以,我们推荐使用@Repository、@Service、@Controller来替代@Component。
6.使用<context:component-scan />让Bean定义注解工作起来
细谈Spring(五)spring之AOP底层大揭秘
众所周知,java是面向对象语言的有力代表,提到java我们就会立即想到面向对象,提到面向对象我们就会想到java。然而面向对象也并非完美无缺的,它更注重于对象层次结构方面的东西,对于如何更好的管理对象行为内部结构,还存在着些许不足。那么我们如何使这个问题的得到更完美的解决呢?答案就是AOP。
AOP:Aspect-Oriented Programming。AOP是OOP的补充,是GOF的延续。我们知道设计模式是对于面向对象设计中经验的总结,它孜孜不断追求的就是调用者与被调用者之间的解耦。有了设计模式我们可以更有效的利用面向对象的特性,使得整个软件设计更加灵活、优雅。但是设计模式是基于面向对象的思想而形成的,更多的时候关注的是对象层次的东西,在解决对象行为内部问题方面却有些不足。AOP的出现恰恰就是对面向对象思想做出了完美的补充。
说到AOP,我们就不得不来提一下软件的纵向和横向问题。从纵向结构来看就是我们软件系统的各个模块,它主要负责处理我们的核心业务(例如商品订购、购物车查看);而从横向结构来看,我们几乎每个系统又包含一些公共模块(例如权限、日志模块等)。这些公共模块分布于我们各个核心业务之中(例如订购和查看商品明细的过程都需要检查用户权限、记录系统日志等)。这样一来不仅在开发过程中要处处关注公共模块的处理而且开发后维护起来也是十分麻烦。而有了AOP之后将应用程序中的商业逻辑同对其提供支持的通用服务进行分离,使得开发人员可以更多的关注核心业务开发。
下面我们就以一个简单的例子来看一下AOP吧!比如说,我们现在要开发的一个应用里面有很多的业务方法,但是,我们现在要对这个方法的执行做全面监控,或部分监控.也许我们就会在要一些方法前去加上一条日志记录,我们写个例子看看我们最简单的解决方案
我们先写一个接口IHello.java代码如下:
里面有个方法,用于输入"Hello" 加传进来的姓名;我们去写个类实现IHello接口
现在我们要为这个业务方法加上日志记录的业务 , 我们在不改变原代码的情况下 , 我们会去怎么做呢 ? 也许 , 你会去写一个类去实现 IHello 接口 , 并依赖 Hello 这个类 . 代码如下 :
从上面的代码我们可以看出,hello对象是被HelloProxy这个所谓的代理态所创建的.这样,如果我们以后要把日志记录的功能去掉.那我们只要把得到hello对象的的具体实现改为Hello的就可以。上面的代码 就是对AOP的最简单的视线,但是我们接下来想,如果我们要在很多业务逻辑之前加日志的话,那么,我们是不是要去写很多个HelloProxy这样的类呢.没错,是的.其实也是一种很麻烦的事.在jdk1.3以后.jdk跟我们提供了一个API java.lang.reflect.InvocationHandler的类. 这个类可以让我们在JVM调用某个类的方法时动态的为些方法做些什么事.让我们把以上的代码改一下来看看效果.
同样,我们写一个IHello的接口和一个Hello的实现类.在接口中.我们定义两个方法;代码如下 :
IHello.java
Hello.java
我们一样的去写一个代理类.只不过.让这个类去实现java.lang.reflect.InvocationHandler接口,代码如下:
从上面的例子我们看出.只要你是采用面向接口编程,那么,你的任何对象的方法执行之前要加上记录日志的操作都是可以的.他(DynaPoxyHello)自动去代理执行被代理对象(Hello)中的每一个方法,一个java.lang.reflect.InvocationHandler接口就把我们的代理对象和被代理对象解藕了
细谈Spring(六)spring之AOP基本概念和配置详解
首先我们来看一下官方文档所给我们的关于AOP的一些概念性词语的解释:
切面(Aspect):一个关注点的模块化,这个关注点可能会横切多个对象。事务管理是J2EE应用中一个关于横切关注点的很好的例子。在Spring AOP中,切面可以使用基于模式)或者基于Aspect注解方式来实现。通俗点说就是我们加入的切面类(比如log类),可以这么理解。
连接点(Joinpoint):在程序执行过程中某个特定的点,比如某方法调用的时候或者处理异常的时候。在Spring AOP中,一个连接点总是表示一个方法的执行。通俗的说就是加入切点的那个点
通知(Advice):在切面的某个特定的连接点上执行的动作。其中包括了“around”、“before”和“after”等不同类型的通知(通知的类型将在后面部分进行讨论)。许多AOP框架(包括Spring)都是以拦截器做通知模型,并维护一个以连接点为中心的拦截器链。
切入点(Pointcut):匹配连接点的断言。通知和一个切入点表达式关联,并在满足这个切入点的连接点上运行(例如,当执行某个特定名称的方法时)。切入点表达式如何和连接点匹配是AOP的核心:Spring缺省使用AspectJ切入点语法。
引入(Introduction):用来给一个类型声明额外的方法或属性(也被称为连接类型声明(inter-type declaration))。Spring允许引入新的接口(以及一个对应的实现)到任何被代理的对象。例如,你可以使用引入来使一个bean实现IsModified接口,以便简化缓存机制。
目标对象(Target Object): 被一个或者多个切面所通知的对象。也被称做被通知(advised)对象。 既然Spring AOP是通过运行时代理实现的,这个对象永远是一个被代理(proxied)对象。
AOP代理(AOP Proxy):AOP框架创建的对象,用来实现切面契约(例如通知方法执行等等)。在Spring中,AOP代理可以是JDK动态代理或者CGLIB代理。
织入(Weaving):把切面连接到其它的应用程序类型或者对象上,并创建一个被通知的对象。这些可以在编译时(例如使用AspectJ编译器),类加载时和运行时完成。Spring和其他纯Java AOP框架一样,在运行时完成织入。
通知类型:
前置通知(Before advice):在某连接点之前执行的通知,但这个通知不能阻止连接点之前的执行流程(除非它抛出一个异常)。
后置通知(After returning advice):在某连接点正常完成后执行的通知:例如,一个方法没有抛出任何异常,正常返回。
异常通知(After throwing advice):在方法抛出异常退出时执行的通知。
最终通知(After (finally) advice):当某连接点退出的时候执行的通知(不论是正常返回还是异常退出)。
环绕通知(Around Advice):包围一个连接点的通知,如方法调用。这是最强大的一种通知类型。环绕通知可以在方法调用前后完成自定义的行为。它也会选择是否继续执行连接点或直接返回它自己的返回值或抛出异常来结束执行。
环绕通知是最常用的通知类型。和AspectJ一样,Spring提供所有类型的通知,我们推荐你使用尽可能简单的通知类型来实现需要的功能。例如,如果你只是需要一个方法的返回值来更新缓存,最好使用后置通知而不是环绕通知,尽管环绕通知也能完成同样的事情。用最合适的通知类型可以使得编程模型变得简单,并且能够避免很多潜在的错误。比如,你不需要在JoinPoint上调用用于环绕通知的proceed()方法,就不会有调用的问题。
spring AOP的实现
在spring2.5中,常用的AOP实现方式有两种。第一种是基于xml配置文件方式的实现,第二种是基于注解方式的实现。接下来,以具体的示例来讲解这两种方式的使用。下面我们要用到的实例是一个注册,就有用户名和密码,我们利用AOP来实现在用户注册的时候实现在保存数据之前和之后或者是抛出异常时,在这些情况下都给他加上日志。在这里我们只讲解AOP,所以我只把关键代码贴出来,不相干的就不贴了。
首先我们来看一下业务逻辑service层:
对于业务系统来说,RegisterServiceImpl类就是目标实现类,它的业务方法,如save()方法的前后或代码会出现异常的地方都是AOP的连接点。
下面是日志服务类的代码:
这个类属于业务服务类,如果用AOP的术语来说,它就是一个切面类,它定义了许多通知。Before()、afterReturn()、after()和afterThrowing()这些方法都是通知。
下面我们就来看具体配置,首先来看一下:
<1>.基于xml配置文件的AOP实现:这种方式在实现AOP时,有4个步骤。
上述配置针对切入点应用了前置、后置、最终,以及抛出异常后通知。这样在测试执行RegisterServiceImpl类的save()方法时,控制台会有如下结果输出:
前置通知:com.zxf.service.RegisterServiceImpl类的save方法开始了。
针对MySQL的RegisterDao实现中的save()方法。
后置通知:方法正常结束了。
最终通知:不管方法有没有正常执行完成,一定会返回的。
下面我们在来看一下第二种配置方式:
<2>基于注解的AOP的实现
首先创建一个用来作为切面的类LogAnnotationAspect,同时把这个类配置在spring的配置文件中。
在spring2.0以后引入了JDK5.0的注解Annotation的支持,提供了对AspectJ基于注解的切面的支持,从而 更进一步地简化AOP的配置。具体的步骤有两步。
Spring的配置文件是如下的配置:
这是那个切面的类LogAnnotationAspect
备注:输出结果和前面的一样。
细谈Spring(七)spring之JDBC访问数据库及配置详解
利用spring访问数据库是我们ssh程序中必不可少的步骤,在没有hibernate之前,我们一般都用jdbc访问数据库,所以用jdbc访问数据库必不可少的要进行一些配置,spring中为我们提供了访问数据库的数据源配置,配置完以后我们就可以很容易的利用jdbc对数据库进行访问了。下面我们就具体来看一下spring所支持的集中jdbc数据源的配置:
在Sping的配置文件中,关于dataSource的配置,就我们常用的方法大致可以有三种:
1、一般的配置方法,直接在配置中指定其值。具体的例子我们参照Mysql的配置如下:
2.、通过读取文件信息资源,其原理与方法一相同。示例:
在上述方法配置成功之后,我们可以通过JdbcTemplate把dataSource注入到JdbcTemplate里面
配置完这些之后我们就可以利用JdbcTemplate来访问数据库了。利用JdbcTemplate访问数据库要比一般的jdbc访问数据库方便的多,也简单的多,直接调用相关的访问就OK了,也不用管什么关闭和打开链接。下面我们就以一个保存用户实例来简单看一下JdbcTemplate的基本用法:
我们看一下在beans.xml中对userdao的基本配置:
好了,这样就可以利用spring给我们提供的API进行JDBC访问数据库了,这个知识点比较简单,我们就先说到这。
细谈Spring(八)spring+hibernate整合基本详解
由于Spring和Hibernate处于不同的层次,Spring关心的是业务逻辑之间的组合关系,Spring提供了对他们的强大的管理能力, 而Hibernate完成了OR的映射,使开发人员不用再去关心SQL语句,直接与对象打交道。 将Hibernate做完映射之后的对象交给Spring来管理是再合适不过的事情了, Spring也同时提供了对Hibernate的SessionFactory的集成功能。所以spring+hibernate整合对我们实际开发是非常有必要的。Spring整合hibernate有多种方式,我用的只是其中的一种,我这种不需要hibernate的配置文件,直接配置我们的beans.xml里了。下面我们具体来看一下:
首先我们先把需要的实体类定义出来,我这里定义的是:
这里我们整合spring+hibernate主要是来整合的细节,业务逻辑和分层在此就忽略不计了,我直接把所有的东西都写在了test类里面了。
下面我们来看一下我们的beans.xml的配置,我们先把代码贴出来,然后再下面一点点的深入详解:
Beans.xml:
通过上面的注释我想大家应该大体对这个配置文件明白些了吧。其实这个也很好理解,大体思路就是首先写一个datasource的bean,这个bean主要是为hibernate提供数据源,大家肯定可以想到这个数据源将会被注入到sessionfactory里面,因为构建sessionfactory肯定会需要到这个数据源的信息。
下一步我们在写一个sessionfactory的bean,这个bean将被我们用在注入到dao层,进行数据库操作,当然,他还需要一些属性进行注入,比如我们刚才写的datasource,除了这个之外我们还需要配置我们的实体,spring给我们提供了hbm文件和实体类等多种配置方法。Hbm文件配置我们这样写:
属性值为mappingResources,这个属性值是一个list,我们可以配置他的value,把我们的配置文件一个个的加入进来。如果你没有写配置文件,而是以注解的方式配置的实体类,你当然也可以以实体类的形式加到这里来:你可以以下方式进行配置:把属性的name设置成annotatedClasses
说完配置sessionfactory的的实体,下一步我们还要配置hibernate的的一些属性,比如创建数据库表的方式、数据库方言等。设置hibernate的属性,我们用hibernateProperties来配置,配置方式,上面代码已经很清楚的写到了,在这就不赘述了。
好了,配置完sessionfactory这个bean,下一步我们就要把sessionfactory注入到我们的dao层进行数据库操作了。这一步就比较简单了,相信大家能看懂上面的代码。
看完配置文件,接下来我们就要来测试一下来,试试能不能用hibernate对我们的数据库进行访问了。具体来看一下代码:
大家可以清楚的看到,上面的内容很简单,我们写具体的架构的东西,直接把sessionfactory注入到了test类了,当然了,我们实际开发应用中不会手动的去加载beans.xml的,这里主要是为了测试,测试一下:
打印出sql语句:
Hibernate: insert into users (name) values (?)
好了,基本上我们这个hibernate+spring整合的差不多了。但在调试这个程序的时候还是出了点小差错,最后弄了半天才发现错误所在,我刚开始写的时候,是把main里面的操作都抽出一个方法了,然后再main方法中我是这样调用的new Test().sava(user),直接就出事了。异常的原因就是我new出来的test的对象就不受spring容器管理了,所以在调用save方法时根本sessionfactory就没有被注入进去,所以希望大家注意这一点。
细谈Spring(九)spring+hibernate声明式事务管理详解
声明式事务管理是spring对事务管理的最常用的方式,因为这种方式对代码的影响最小,因此也符合非侵入性的轻量级容器的概念。Spring的事务管理是通过AOP的方式来实现的,因为事务方面的代码与spring的绑定并以一种样板式结构使用。在理解spring声明式事务管理我们首先要理解他是通过AOP怎么具体实现的。其中的事务通知由元数据(目前基于xml和注解)驱动。代理对象由元数据结合产生一个新的代理对象。他使用一个PlatformTransactionManager实现配合TransactionInterceptor在方法调用之前实施事务。下面我们就通过一个图来看一下spring声明式事务管理的执行过程。
下面我们就以一个spring官方文档所给的例子来具体看一下用xml配置方式怎么来实现声明式事务管理:
首先请看下面的接口和它的实现。这个例子的意图是介绍概念:
// 我们想做成事务性的服务接口
// 上述接口的一个实现
首先要解释的是很多同学可能都在考虑这个事务管理到底是放在dao层还是放在service层呢。这个问题我想大多数童鞋的反应应该都是在dao层上吧,刚开始我也是这么想的。但是大家想想,如果我们要进行两个甚至多个dao层中的方法操作,并且要求放在同一个事务里时,我们该怎么来管理这个事务呢,这时我们就没办法了。所以我们应该把事务管理放在service层中,我们直接在service层中调用这两个dao层的方法就oK了。
下面我们接着往下看,我们假定,FooService的前两个方法(getFoo(String) 和getFoo(String, String))必须执行在只读事务上下文中,其他的方法(insertFoo(Foo)和 updateFoo(Foo))必须执行在可读写事务上下文中。我们根据这个要求来看一下配置文件,我们刚开始可能看不懂,不用慌,往下我们会一一解释的。
好了,配置一大片,什么东西,我也看不懂,呵呵,没关系,一会大家就明白了,我们先来看一下官方给的解释,然后我在根据我自己的理解给大家通俗的解释一下这里的内容。
我们要把一个服务对象('fooService' bean)做成事务性的。 我们想施加的事务语义封装在<tx:advice/>定义中。<tx:advice/> “把所有以 'get' 开头的方法看做执行在只读事务上下文中, 其余的方法执行在默认语义的事务上下文中”。 其中的 'transaction-manager' 属性被设置为一个指向 PlatformTransactionManager bean的名字(这里指 'txManager'), 该bean将会真正管理事务。配置中最后一段是 <aop:config/> 的定义, 它确保由 'txAdvice' bean定义的事务通知在应用中合适的点被执行。 首先我们定义了 一个切面,它匹配 FooService 接口定义的所有操作, 我们把该切面叫做 'fooServiceOperation'。然后我们用一个通知器(advisor)把这个切面与 'txAdvice' 绑定在一起, 表示当 'fooServiceOperation' 执行时,'txAdvice' 定义的通知逻辑将被执行。
好了,上面就是官方文档给出的这个配置文件的解释,不知道大家有没有看懂,反正对于初学者我的时候,我是真没看懂,不太容易懂,当然了,大牛们是一定能看懂的。下面我就根据我自己的理解来通俗的讲解一下。
首先我们应该要把服务对象'fooService' 声明成一个bean,我们要把一个服务对象('fooService' bean)做成事务性的。我们就应该首先在声明一个事务管理的建议,用什么来管理,spring给我们提供了事务封装,这个就封装在了<tx:advice/>中,这个事务建议给我们提供了一个transaction-manager属性,用他可以指定我们用谁来管理我们的事务。我们上边的例子用的为一个指向 PlatformTransactionManager bean的名字(这里指 'txManager'), 该bean将会真正管理事务。上面用的事务管理类是用的jdbc中提供的事务管理,当然这里也可以指定为hibernate管理。当然了,不管用那个类来管理我们的事务,都不要忘记了提供我们的datasource属性,因为事务管理也需要这里面的信息。我们声明好事务建议,也指定好了具体用哪个类来管理了,下面我们的任务就是要把我们定义好的这些利用AOP把我们的事务管理织入到我们的业务逻辑里面了。<aop:config/> 的定义, 它确保由 'txAdvice' bean定义的事务通知在应用中合适的点被执行。 首先我们定义了 一个切面,它匹配 FooService 接口定义的所有操作, 我们把该切面叫做 'fooServiceOperation'。<aop:pointcut/> 元素定义是AspectJ的切面表示法,上述表示x.y.service.FooService包下的任意方法。然后我们用一个通知器(advisor)把这个切面与 'txAdvice' 绑定在一起, 表示当 'fooServiceOperation' 执行时,'txAdvice' 定义的通知逻辑将被执行。大体流程就是这样的了。
上面的配置将为'fooService' bean创建一个代理对象,这个代理对象被装配了事务通知,所以当它的相应方法被调用时,一个事务将被启动、挂起、被标记为只读,或者其它(根据该方法所配置的事务语义)。
我们来看看下面的例子,测试一下上面的配置。
运行可以清楚的看到如下结果:
- Invoking rollback for transaction on x.y.service.FooService.insertFoo
due to throwable [java.lang.UnsupportedOperationException]
<tx:advice/> 有关的设置
通过 <tx:advice/> 标签来指定不同的事务性设置。默认的 <tx:advice/> 设置如下:
事务传播设置是 REQUIRED
隔离级别是DEFAULT
事务是 读/写
事务超时默认是依赖于事务系统的,或者事务超时没有被支持。
任何 RuntimeException 将触发事务回滚,但是任何 checked Exception 将不触发事务回滚
这些默认的设置当然也是可以被改变的。 <tx:advice/> 和 <tx:attributes/> 标签里的 <tx:method/> 各种属性设置总结如下:
属性 | 是否需要? | 默认值 | 描述 |
name | 是 | 与事务属性关联的方法名。通配符(*)可以用来指定一批关联到相同的事务属性的方法。 如:'get*'、'handle*'、'on*Event'等等。 | |
propagation | 不 | REQUIRED | 事务传播行为 |
isolation | 不 | DEFAULT | 事务隔离级别 |
timeout | 不 | -1 | 事务超时的时间(以秒为单位) |
read-only | 不 | false | 事务是否只读? |
rollback-for | 不 | 将被触发进行回滚的 Exception(s);以逗号分开。 如:'com.foo.MyBusinessException,ServletException' | |
no-rollback-for | 不 | 不 被触发进行回滚的 Exception(s);以逗号分开。 如:'com.foo.MyBusinessException,ServletException' |
下面我们具体来看一下事务的传播性的几个值:
REQUIRED:业务方法需要在一个容器里运行。如果方法运行时,已经处在一个事务中,那么加入到这个事务,否则自己新建一个新的事务。
NOT_SUPPORTED:声明方法不需要事务。如果方法没有关联到一个事务,容器不会为他开启事务,如果方法在一个事务中被调用,该事务会被挂起,调用结束后,原先的事务会恢复执行。
REQUIRESNEW:不管是否存在事务,该方法总汇为自己发起一个新的事务。如果方法已经运行在一个事务中,则原有事务挂起,新的事务被创建。
MANDATORY:该方法只能在一个已经存在的事务中执行,业务方法不能发起自己的事务。如果在没有事务的环境下被调用,容器抛出例外。
SUPPORTS:该方法在某个事务范围内被调用,则方法成为该事务的一部分。如果方法在该事务范围外被调用,该方法就在没有事务的环境下执行。
NEVER:该方法绝对不能在事务范围内执行。如果在就抛例外。只有该方法没有关联到任何事务,才正常执行。
NESTED:如果一个活动的事务存在,则运行在一个嵌套的事务中。如果没有活动事务,则按REQUIRED属性执行。它使用了一个单独的事务,这个事务 拥有多个可以回滚的保存点。内部事务的回滚不会对外部事务造成影响。它只对DataSourceTransactionManager事务管理器起效。
使用 @Transactional
除了基于XML文件的声明式事务配置外,你也可以采用基于注解式的事务配置方法。直接在Java源代码中声明事务语义的做法让事务声明和将受其影响的代码距离更近了,而且一般来说不会有不恰当的耦合的风险,因为,使用事务性的代码几乎总是被部署在事务环境中。
下面的例子很好地演示了 @Transactional 注解的易用性,随后解释其中的细节。先看看其中的类定义:
当上述的POJO定义在Spring IoC容器里时,上述bean实例仅仅通过一 行xml配置就可以使它具有事务性的。如下:
注意: 实际上,如果你用 'transactionManager' 来定义 PlatformTransactionManager bean的名字的话,你就可以忽略 <tx:annotation-driven/> 标签里的 'transaction-manager' 属性。 如果 PlatformTransactionManager bean你要通过其它名称来注入的话,你必须用 'transaction-manager' 属性来指定它。
在多数情形下,方法的事务设置将被优先执行。在下列情况下,例如: DefaultFooService 类在类的级别上被注解为只读事务,但是,这个类中的 updateFoo(Foo) 方法的 @Transactional 注解的事务设置将优先于类级别注解的事务设置。
@Transactional 注解是用来指定接口、类或方法必须拥有事务语义的元数据。 如:“当一个方法开始调用时就开启一个新的只读事务,并停止掉任何现存的事务”。 默认的 @Transactional 设置如下:
事务传播设置是 PROPAGATION_REQUIRED
事务隔离级别是 ISOLATION_DEFAULT
事务是 读/写
事务超时默认是依赖于事务系统的,或者事务超时没有被支持。
任何 RuntimeException 将触发事务回滚,但是任何 checked Exception 将不触发事务回滚
这些默认的设置当然也是可以被改变的。 @Transactional 注解的各种属性设置总结如下:
属性 | 类型 | 描述 |
枚举型:Propagation | 可选的传播性设置 | |
isolation | 枚举型:Isolation | 可选的隔离性级别(默认值:ISOLATION_DEFAULT) |
readOnly | 布尔型 | 读写型事务 vs. 只读型事务 |
timeout | int型(以秒为单位) | 事务超时 |
rollbackFor | 一组 Class 类的实例,必须是Throwable 的子类 | 一组异常类,遇到时 必须 进行回滚。默认情况下checked exceptions不进行回滚,仅unchecked exceptions(即RuntimeException的子类)才进行事务回滚。 |
rollbackForClassname | 一组 Class 类的名字,必须是Throwable的子类 | 一组异常类名,遇到时 必须 进行回滚 |
noRollbackFor | 一组 Class 类的实例,必须是Throwable 的子类 | 一组异常类,遇到时 必须不 回滚。 |
noRollbackForClassname | 一组 Class 类的名字,必须是Throwable 的子类 | 一组异常类,遇到时 必须不 回滚 |
在写代码的时候,不可能对事务的名字有个很清晰的认识,这里的名字是指会在事务监视器(比如WebLogic的事务管理器)或者日志输出中显示的名字, 对于声明式的事务设置,事务名字总是全限定名+"."+事务通知的类的方法名。比如BusinessService类的handlePayment(..)方法启动了一个事务,事务的名称是:
com.foo.BusinessService.handlePayment
细谈Spring(十)深入源码分析Spring之HibernateTemplate 和HibernateDaoSupport
spring提供访问数据库的有三种方式:
HibernateDaoSupport
HibernateTemplate(推荐使用)
jdbcTemplate(我们一般不用)
类所在包:
HibernateTemplate:org.springframework.orm.hibernate3.HibernateTemplate
HibernateDaoSupport:org.springframework.orm.hibernate3.support.HibernateDaoSupport
spring如果想整合hibernate的话,首先就应该获得SessionFactory这个类,然后再通过获得session就可以进行访问数据库了,即spring提供的类HibernateDaoSupport,HibernateTemplate应该是有setSessionFactory,在使用的时候注入一下就可以了。HibernateTemplate类中的方法是spring封装了hibernate中的方法,在使用完了以后会自动释放session。而如果使用了HibernateDaoSupport的getSession方法,就需要配套的用releaseSession(Session session)或者session.close来关闭session,无法实现自动管理session。所以很多人都倾向于用spring的 Hibernatetemplate类或者HibernateDaoSupport的getHibernateTemplate方法来实现实现数据库的交互,当然,如果遇到hibernatetemplate无法实现的功能,可以使用 HibernateDaoSupport。
首先我们先来看一下HibernateTemplate类:
首先我们来说一下我们为什么要用HibernateTemplate,其实这个类就是我们平常使用hibernate进行dao操作的一个模版,我们不需要那些开头的开启事务、获得session,结尾的提交事务,关闭session等操作了,这些工作是HibernateTemplate都给我们封装好了,我们直接调用其dao的操作方法就可以了,并且他还给我们封装了hibernate的几乎所有的异常,这样我们在处理异常的时候就不要记住那么多繁琐的异常了。所以我们就叫他是一个hibernate中dao操作的模版,他提供的常用方法:
get 从数据库相关表中获取一条记录并封装返回一个对象(Object)
load 作用与get基本相同,不过只有在对该对象的数据实际调用时,才会去查询数据库
save 添加记录
saveOrUpdate 判断相应记录是否已存在,据此进行添加或修改记录
update 修改记录
delete 删除记录
下面我们来看一下HibernateTemplate的源码来看一下他的具体方法是怎么样实现的,其实你观察源码可以发现,他所提供的方法几乎都是一个实现实现的。下面我们就以save方法来具体看一下:
我们从源码中可以发现,HibernateTemplate把我们hibernate的异常都封装成了一个DataAccessException 。好了,解释一下上面的代码,上面代码中主要是调用了executeWithNativeSession这个方法,其实这个方法就是给我们封装好的hibernate开头和结尾一些列操作,他需要一个参数,这个参数是一个回调的对象,其实这个对象是实现了一个HibernateCallback的接口,实现这个接口需要实现这个接口里面的方法doInHibernate,这个方法需要把当前的session传递过来,其实他就是把他原先模版里获得的session传过去。然后在在doInHibernate中利用模版中得到的session进行保存数据。其实我们调用save的过程就是给他传一个回调对象的过程,我们可以看到,他的回调对象是new出来的。
如果你还没看懂的话,那大家来看一下下面我们实现自己的HibernateTemplate,他的思路和spring提供的基本是一样的:其中MyHibernateCallback 是一个简单接口:
好了,原理我们介绍完了之后,下面我们来看一下具体应用,这个HibernateTemplate在我们的程序中怎么用,在上面我们也说过了,这个用法主要是把sessionfactory注入给我们的HibernateTemplate
首先我们来看一下beans.xml的配置:
下一步我们来看一下hibernateTemplate的使用:
这基本上就是我们的hibernateTemplate原理及使用了,其实他的使用很简单
下面,我们来看一下HibernateDaoSupport:
通过上面我们可以看出,通过xml注入hibernateTemplate,我们可以想象的到所有DAO类中都会有HibernateTemplate的bean方法,于是上面hibernateTemplate的set、get的方法和xml配置会有大量的,于是就出现了代码冗余和重复,我们怎么才能避免这个重复呢,我们很容易应该能想到,把上面注入hibernateTemplate抽出一个类,然后让我们的dao类来继承这个类。不过这个类Spring已经有了,那就是HibernateDaoSupport,除此之外,HibernateDaoSupport也有SessionFactory的bean方法,所以我们在用HibernateDaoSupport的时候同样也要给我们注入sessionfactory或者hibernateTemplate,在用的时候你会发现HibernateDaoSupport也给我们提供了getHibernateDaoSupport方法。
相关配置示例:userdao继承了HibernateDaoSupport
用上面的方法我们可以发现一个问题,我们同样解决不了xml配置重复的问题,我们每一个dao都要在xml注入sessionfactory或者hibernateTemplate,解决这个问题的办法就是我们自己在抽出一个SuperDao类,让这个类去继承HibernateDaoSupport,然后我们给SuperDao类去配置,这样的话,我们在我的dao类中直接去继承SuperDao类就可以了,这样不管有多少dao类,只要继承SuperDao,我们就可以实现我们想要的功能了。
细谈Spring(十一)深入理解spring+struts2整合(附源码)
Spring和struts2是我们在项目架构中用的比较多的两个框架,怎么才能把这两个框架用好,怎么来整合是我们掌握运用这两个框架的关键点,下面我们就怎么来整合,从哪来整合,为什么要整合,从这几点来看一下struts2和spring的整合。下面我们来具体分析一下:
我们一起来想想,如果让spring和struts2进行整合,我们就希望我们可以在spring中直接注入action,spring容器初始化的时候就给我们建好了action,但是事情不像我们想象的那么简单,因为struts2的action是由struts2自己new出来的,他不受spring的管理,所以无法自动注入。所以struts和spring的整合的结合点在于,struts2的action不能直接入service。好了,既然有了问题,spring或者struts2肯定已经为我们把这个问题解决了。struts2解决这个问题是他给我们提供了一个struts-spring-plugin的插件,通过这个插件我们就可以把我们的struts2和是spring进行整合了。struts-spring-plugin将会对我们的action进行管理,当spring需要action的时候他就可以向struts-spring-plugin来要了。
源码下载:用力点
下面我们就具体的来看一下struts+spring的整合过程:
1.需要的jar包列表:Struts2.1.6 + Spring2.5.6 + Hibernate3.3.2
jar包名称 | 所在位置 | 说明 |
antlr-2.7.6.jar | hibernate/lib/required | 解析HQL |
aspectjrt | spring/lib/aspectj | AOP |
aspectjweaver | .. | AOP |
cglib-nodep-2.1_3.jar | spring/lib/cglib | 代理,二进制增强 |
common-annotations.jar | spring/lib/j2ee | @Resource |
commons-collections-3.1.jar | hibernate/lib/required | 集合框架 |
commons-fileupload-1.2.1.jar | struts/lib | struts |
commons-io-1.3.2 | struts/lib | struts |
commons-logging-1.1.1 | 单独下载,删除1.0.4(struts/lib) | struts spring |
dom4j-1.6.1.jar | hibernate/required | 解析xml |
ejb3-persistence | hibernate-annotation/lib | @Entity |
freemarker-2.3.13 | struts/lib | struts |
hibernate3.jar | hibernate | |
hibernate-annotations | hibernate-annotation/ | |
hibernate-common-annotations | hibernate-annotation/lib | |
javassist-3.9.0.GA.jar | hiberante/lib/required | hibernate |
jta-1.1.jar | .. | hibernate transaction |
junit4.5 | ||
mysql- | ||
ognl-2.6.11.jar | struts/lib | |
slf4j-api-1.5.8.jar | hibernate/lib/required | hibernate-log |
slf4j-nop-1.5.8.jar | hibernate/lib/required | |
spring.jar | spring/dist | |
struts2-core-2.1.6.jar | struts/lib | |
xwork-2.1.2.jar | struts/lib | struts2 |
commons-dbcp | spring/lib/jarkata-commons | |
commons-pool.jar | .. | |
struts2-spring-plugin-2.1.6.jar | struts/lib |
2.配置好jar包以后,如果我们想在服务器一启动就可以让spring容器自动去加载我们在配置文件中配置的bean,那么我们要在web.xml中去配置一个监听器,这个监听器的作用是监听我们的application,一旦我们的项目启动就触发了监听器,我们来看一下这个监听器的配置:
如果你的配置文件不想放在默认的位置,而是自己去指定位置,那么我们将要在web.xml中再次配置如下:
加载完上面的bean之后,我们就要考虑去管理我们的action了,我们应该让spring去找struts去要相应的action,把action实例化为响应的bean,这时我们就需要我们上边所提到的struts-spring-plugin这个jar包了。加上这个jar包之后我们就可以让spring来管理我们的action了。在struts-spring-plugin中有一个struts--plugin。Xml文件。下面我们来看一下这个文件中的配置执行的具体过程:
关键是这个 <constant name="struts.objectFactory" value="spring" />,这句配置就指明了我们产生struts对象的工厂交给spring来产生,我们来看一下具体步骤:
struts2一起动就会去加载配置文件,其中包括struts—plugin。xml读取顺序:
struts的读常量:
struts-default.xml
struts-plugin.xml
struts.xml
struts.properties
web.xml
struts-plugin.xml指明了我们产生对象的工厂交给spring来完成,当执行到web.xml时,由于spring容器的监听器,这时spring容器就开始启动,spring启动之后会web.xml去找相应的配置,在web.xml中可以找到spring中的配置文件beans.xml,然后去初始化所有的bean。
spring去加载beans.xml的时候会自动把所有的bean初始化,并且放在自己的容器里。与此同时,struts2也有自己的bean容器,这个容器是struts—plugin提供的,他会把所有的action加载都加载到自己的容器里。然后根据action的属性名字自动去spring去找名字和action属性相同的bean直接注入到action中,也就是说。我们在action中其实不用配置注入的东西,struts容器会自动给我们注入。但还是要提供相应的set、get方法。并且名字要约定好,action属性和spring中的bean的id要一样。但不要忘记,action的scope设置成prototype
下面我们来看一下具体的示例代码:
需要注意的是,spring和struts2整合的时候有一个属性struts.objectFactory.spring.autoware,也就是说是struts属性的的自动装配类型,他的默认值是name,也就是说struts中的action中的属性不需要配置,他默认的去beans.xml中去找名字相同的,应该注意的是,在给一些属性起名字的时候不要和spring中配置的action的name属性相同,否则会报异常
下面我们来看一下struts.xml和beans.xml的相关配置:
Struts.xml:
Beans.xml
上面的示例是用的struts2的容器来产生action,spring需要的时候要去struts容器里面去找action,然后再初始化bean,其实我们还有一种方法产生action,那就是让spring容器去帮我们来产生action,这样我们产生action的时候就可以去spring容器里面去找了,具体应该是在spring配置文件beans.xml中把对应的action配置成bean,然后再struts.xml中配置action的时候,action对应的class就不再是配置成该action对应的类了,而是配置这个action对应的spring容器的bean的id属性,这样action初始化的时候就会去spring容器里面去找了。但是这样配置的话,我们的action属性就必须配置了,因为spring来产生action后,struts容器就不会在自动去给我们注入属性了。如果不配置属性的话会产生异常,下面我们来看一下具体配置情况:
Action的代码还是以前的代码,没有改变,这里就不再重复写了,下面我们来看一下struts.xml的配置:
Struts.xml
上面的class对应的是下面action中bean的id属性
Beans.xml
细谈Spring(十二)OpenSessionInView详解及用法
首先我们来看一下什么是OpenSessionInView?
在hibernate中使用load方法时,并未把数据真正获取时就关闭了session,当我们真正想获取数据时会迫使load加载数据,而此时session已关闭,所以就会出现异常。 比较典型的是在MVC模式中,我们在M层调用持久层获取数据时(持久层用的是load方法加载数据),当这一调用结束时,session随之关闭,而我们希望在V层使用这些数据,这时才会迫使load加载数据,我们就希望这时的session是open着得,这就是所谓的Open Session In view 。 我们可以用filter来达到此目的。 这段话引至于百度百科,但确实很好的说明了OpenSessionInView这个过滤器的作用。
OpenSessionInViewFilter是Spring提供的一个针对Hibernate的一个支持类,其主要意思是在发起一个页面请求时打开Hibernate的Session,一直保持这个Session,直到这个请求结束,具体是通过一个Filter来实现的。 由于Hibernate引入了Lazy Load特性,使得脱离Hibernate的Session周期的对象如果再想通过getter方法取到其关联对象的值,Hibernate会抛出一个LazyLoad的Exception。所以为了解决这个问题,Spring引入了这个Filter,使得Hibernate的Session的生命周期变长。
首先分析一下它的源码,可以发现,它所实现的功能其实比较简单:
在上述代码中,首先获得SessionFactory,然后通过SessionFactory获得一个Session。然后执行真正的Action代码,最后根据情况将Hibernate的Session进行关闭。整个思路比较清晰。
下面我们来看一下他的具体配置,其实很简单,直接在web.xml中把他这个filter配置上就ok了:
在上面配置中我们要注意以下几点:
1、这个filter一定要配置在struts的过滤器的前面,因为过滤器是“先进后出”原则,如果你配置在struts的后面的话,你的openSessionInView过滤器都执行完了,怎么在去在管理action的转向页面啊。
2、Opensessioninview也需要sessionfactory的bean的注入,他默认的去找bean的id为sessionfactory的bean,如果sessionfactory的bean的id不是这个名字的话,要记得给这个过滤器配置一个参数,参数名为sessionfactoryBeanName,把他的value设置为你的sessionfactory的bean的id值。
3、在用opensessioninview的时候一定要注意,如果你不配置transaction的话,在用opensessioninview时,他默认的把事务配置为only-read只读,这样的话,如果你进行增删改的时候,他就会报一个在只读事务中不能进行增删改的操作。如果把opensessioninview去掉,他默认的事务的开始边界就锁定在dao层操作上,dao层hibernatetempt提供了事务的开始和提交
OpenSessionInView的副作用
了解了上面几个问题之后,那么也就可以大概知道OpenSessionInView的副作用 – 资源占用严重,配置不当,影响系统性能。使用OpenSessionInView后,在request发出和response返回的流程中,如果有任何一步被阻塞,那在这期间connection就会被一直占用而不释放。比如页面较大,显示需要时间 或者 网速太慢,服务器与用户间传输的时间太长,这都会导致资源占用,最直接的表现就是连接池连接不够用,而导致最终服务器无法提供服务。