A Bit of Background

Ok, I lied: there is some background first. If you really want to learn about the new features, feel free to skip to the next section.

For me, work on REST started about two years ago, shortly after reading the highly recommended book RESTful Web Services from O'Reilly, by Leonard Richardson and Sam Ruby. Initially, I was thinking about adding REST support to Spring Web Services, but after working a couple of weeks on a prototype, it became clear to me that this wasn't a very good fit. In particular, I found out that I had to copy most of the logic from the Spring-MVC DispatcherServlet over to Spring-WS. Clearly, this was not the way to go forward.

Around the same time we introduced the annotation-based model of Spring MVC. This model was clearly an improvement to the former, inheritance-based model. Another interesting development at that time was the development of the JAX-RS specification. My next attempt was to try and merge these two models: to try and combine the @MVC annotations with the JAX-RS annotations, and to be able to run JAX-RS applications within the DispatcherServlet. While I did get a working prototype out of this effort, the result was not satisfactory. There were a number of technical issues which I won't bore you with, but most importantly the approach felt 'clunky' and unnatural for a developer who was already used to Spring MVC 2.5.

Finally, we decided to add the RESTful functionality to features to Spring MVC itself. Obviously, that would mean that there would be some overlap with JAX-RS, but at least the programming model would be satisfactory for Spring MVC developers, both existing and new ones. Additionally, there are already three JAX-RS implementations offering Spring support (Jersey, RESTEasy, and Restlet). Adding a fourth to this list did not seem a good use of our valuable time.

RESTful features in Spring MVC 3.0

Now, enough of the background, let's look at the features!

URI Templates

A URI template is a URI-like string, containing one or more variable names. When these variables are substituted for values, the template becomes a URI. For more information, see the proposed RFC.

In Spring 3.0 M1, we introduced the use of URI templates through the @PathVariable annotation. For instance:

When a request comes in for /hotels/1, that 1 will be bound to the hotelId parameter. You can optionally specify the variable name the parameter is bound to, but when you compile your code with debugging enabled that is not necessary: we infer the path variable name from the parameter name.

You can also have more than one path variable, like so:

This would match requests like /hotels/1/bookings/2, for instance.

You can also combine the use of Ant-style paths and path variables, like so:

and you can use data binding, too:

The above would match /hotels/1/dates/2008-12-18, for instance.

Content Negotiation

In version 2.5, Spring-MVC lets the @Controller decide which view to render for a given request, through its View, view name, and ViewResolver abstractions. In a RESTful scenario, it is common to let the client decide the acceptable representations, via the Accept HTTP header. The server responds with the delivered representation via the Content-Type header. This process is known as content negotiation.

One issue with the Accept header is that is impossible to change it in a web browser, in HTML. For instance, in Firefox, it's fixed to

So what if you want to link to a PDF version of a particular resource? Looking at the file extension is a good workaround. For example, http://example.com/hotels.pdf retrieves the PDF view of the hotel list, as does http://example.com/hotels with an Accept header of application/pdf.

This is what the ContentNegotiatingViewResolver does: it wraps one or more other ViewResolvers, looks at the Accept header or file extension, and resolves a view corresponding to these. In an upcoming blog post, Alef Arendsen will show you how to use the ContentNegotiatingViewResolver.

Views

We also added some new Views to Spring MVC, particularly:

• the AbstractAtomFeedView and AbstractRssFeedView, which can be used to return an Atom and RSS feed,
• the MarshallingView, which can be used to return an XML representation. This view is based on the Object/XML Mapping module, which has been copied from the Spring Web Services project. This module wraps XML marshalling technologies such as JAXB, Castor, JiBX, and more, and makes it easier to configure these within a Spring application context,
• the JacksonJsonView, for JSON representations of objects in your model. This view is actually part of the Spring JavaScript project, which we'll talk about more in a future blog post.

Obviously, these work great in combination with the ContentNegotiatingViewResolver!

HTTP Method Conversion

Another key principle of REST is the use of the Uniform Interface. Basically, this means that all resources (URLs) can be manipulated using the same four HTTP method: GET, PUT, POST, and DELETE. For each of methods, the HTTP specification defines exact semantics. For instance, a GET should always be a safe operation, meaning that is has no side effects, and a PUT or DELETE should be idempotent, meaning that you can repeat these operations over and over again, but the end result should be the same.

While HTTP defines these four methods, HTML only supports two: GET and POST. Fortunately, there are two possible workarounds: you can either use JavaScript to do your PUT or DELETE, or simply do a POST with the 'real' method as an additional parameter (modeled as a hidden input field in an HTML form). This latter trick is what the HiddenHttpMethodFilter does. This filter was introduced in Spring 3.0 M1, and is a plain Servlet Filter. As such, it can be used in combination with any web framework (not just Spring MVC). Simply add this filter to your web.xml, and a POST with a hidden _method parameter will be converted into the corresponding HTTP method request.

As an extra bonus, we've also added support for method conversion in the Spring MVC form tags. For example, the following snippet taken from the updated Petclinic sample:

will actually perform an HTTP POST, with the 'real' DELETE method hidden behind a request parameter, to be picked up by the HiddenHttpMethodFilter. The corresponding @Controller method is therefore:

ETag support

An ETag (entity tag) is an HTTP response header returned by an HTTP/1.1 compliant web server used to determine change in content at a given URL. It can be considered to be the more sophisticated successor to the Last-Modified header. When a server returns a representation with an ETag header, client can use this header in subsequent GETs, in a If-None-Match header. If the content has not changed, the server will return 304: Not Modified.

In Spring 3.0 M1, we introduced the ShallowEtagHeaderFilter. This is a plain Servlet Filter, and thus can be used in combination any web framework. As the name indicates, the filter creates so-called shallow ETags (as opposed to a deep ETags, more about that later). The way it works is quite simple: the filter simply caches the content of the rendered JSP (or other content), generates a MD5 hash over that, and returns that as a ETag header in the response. The next time a client sends a request for the same resource, it use that hash as the If-None-Match value. The filter notices this, renders the view again, and compares the two hashes. If they are equal, a 304 is returned. It is important to note that this filter will not save processing power, as the view is still rendered. The only thing it saves is bandwith, as the rendered response is not sent back over the wire.

Deep ETags are a bit more complicated. In this case, the ETag is based on the underlying domain objects, RDMBS tables, etc. Using this approach, no content is generated unless the underlying data has changed. Unfortunately, implementing this approach in a generic way is much more difficult than shallow ETags. We might add support for deep ETags in a later version of Spring, by relying on JPA's @Version annotation, or an AspectJ aspect for instance.

And more!

In a following post, I will conclude my RESTful journey, and talk about the RestTemplate, which was also introduced in Spring 3.0 M2. This class gives you client-side access to RESTful resources in a fashion similar to the JdbcTemplate, JmsTemplate, etc.

Similar Posts

• REST in Spring 3: RestTemplate
• Adding an Atom view to an application using Spring's REST support
• Pluggable styling with SpringSource Slices
• AOP Context Binding With Named Pointcuts
• Annotated Web MVC Controllers in Spring 2.5

解决方案:

   JavaEE版本和JavaMail的版本不一致,请将sun公司上下载最新版本.http://java.sun.com/products/javamail/downloads/index.html
   例如:javaMail 1.3以下的如果在javaEE5上就会出现上面的错误,
   如果还出现此问题，则是因为javaEE5中包含有javaMail的类但是却不全面,所以出本身的JavaMail
   包冲突.用rar打开X:/Program Files/MyEclipse 6.0/myeclipse/eclipse/plugins/com.genuitec.eclipse.j2eedt.core_x.x.x.zmyeclipsexxxxxxxxx/data/libraryset/EE_5/javaee.jar
,然后删除mail,一切就ok了.

写完部署什么都没问题，可当我写了测试类进行测试时发现主键的初始值竟然是50，其步长亦是50，在同事的帮助下发现原来是Hibernate在做鬼，@SequenceGenerator中添加两个参数（allocationSize = 1, initialValue = 1）就OK。通过查找Hibernate的资料发现原来是因为allocationSize的默认值是50.具体请参考http://www.oracle.com/technology/global/cn/products/ias/toplink/jpa/resources/toplink-jpa-annotations.html#SequenceGenerator

只需要增加allocationSize = 1就可以

在内部，Spring使用BeanPostProcessors 来处理它能找到的标志接口以及调用适当的方法。如果你需要自定义的特性或者其他的Spring没有提供的生命周期行为，你可以实现自己的 BeanPostProcessor。关于这方面更多的内容可以看这里：第 3.7 节“使用BeanPostprocessors定制bean”。

所有的生命周期的标志接口都在下面叙述。在附录的一节中，你可以找到相应的图，展示了Spring如何管理bean；那些生命周期的特性如何改变你的bean的本质特征以及它们如何被管理。

1. InitializingBean / init-method

实现org.springframework.beans.factory.InitializingBean 接口允许一个bean在它的所有必须的属性被BeanFactory设置后，来执行初始化的工作。InitializingBean接口仅仅制定了一个方法：

    * Invoked by a BeanFactory after it has set all bean properties supplied    * (and satisfied BeanFactoryAware and ApplicationContextAware).    * <p>This method allows the bean instance to perform initialization only    * possible when all bean properties have been set and to throw an    * exception in the event of misconfiguration.    * @throws Exception in the event of misconfiguration (such    * as failure to set an essential property) or if initialization fails.    */    void afterPropertiesSet() throws Exception;

注意：通常InitializingBean接口的使用是能够避免的（而且不鼓励，因为没有必要把代码同Spring耦合起来）。Bean的定义支持指定一个普通的初始化方法。在使用XmlBeanFactory的情况下，可以通过指定init-method属性来完成。举例来说，下面的定义：

<bean id="exampleInitBean" class="examples.ExampleBean" init-method="init"/>public class ExampleBean {    public void init() {        // do some initialization work    }}

同下面的完全一样：

<bean id="exampleInitBean" class="examples.AnotherExampleBean"/>public class AnotherExampleBean implements InitializingBean {    public void afterPropertiesSet() {        // do some initialization work    }}

但却不把代码耦合于Spring。

2. DisposableBean / destroy-method

实现org.springframework.beans.factory.DisposableBean接口允许一个bean，可以在包含它的BeanFactory销毁的时候得到一个回调。DisposableBean也只指定了一个方法：

    /**    * Invoked by a BeanFactory on destruction of a singleton.    * @throws Exception in case of shutdown errors.    * Exceptions will get logged but not rethrown to allow    * other beans to release their resources too.    */    void destroy() throws Exception;

注意：通常DisposableBean接口的使用能够避免的（而且是不鼓励的，因为它不必要地将代码耦合于Spring）。 Bean的定义支持指定一个普通的析构方法。在使用XmlBeanFactory使用的情况下，它是通过 destroy-method属性完成。举例来说，下面的定义：

<bean id="exampleInitBean" class="examples.ExampleBean" destroy-method="destroy"/>public class ExampleBean {    public void cleanup() {        // do some destruction work (like closing connection)    }}

同下面的完全一样：

<bean id="exampleInitBean" class="examples.AnotherExampleBean"/>public class AnotherExampleBean implements DisposableBean {    public void destroy() {        // do some destruction work    }}

但却不把代码耦合于Spring。

重要的提示：当以portotype模式部署一个bean的时候，bean的生命周期将会有少许的变化。通过定义，Spring无法管理一个non-singleton/prototype bean的整个生命周期，因为当它创建之后，它被交给客户端而且容器根本不再留意它了。当说起non-singleton/prototype bean的时候，你可以把Spring的角色想象成“new”操作符的替代品。从那之后的任何生命周期方面的事情都由客户端来处理。BeanFactory中bean的生命周期将会在第 3.4.1 节“生命周期接口”一节中有更详细的叙述 .

这个类主要在使用的时候当作获得数据源的标志使用。
二、建立一个获得和设置上下文的类：

BindException  bindObject(ServletRequest request, Object command)
1.Bind And Validate的完整使用代码：
     public BindingResult bindBook(HttpServletRequest request, Book book) throws Exception
    {
 Integer category_id = new Integer(request.getParameter("category.id"));
        book.setCategory(bookManager.getCategory(category_id));
        binder.setDisallowedFields(new String[]{"category"});
addValidator(new BookValiator());
        return bindObject(request, book);
}
  其中第1-3句是绑定不能自动绑定的Category对象，（另外一个方案是实现Category的PropertityEditor,并注册，不过这太不实际了）并命令binder忽略这些已被手工绑定的field.
       注意,如果不忽略,binder绑定时则很有可能出错。

  第4句增加validator。

  第5句执行Bind and Validate。

不过，我们一般会重载preBind()函数来完成1-3句的操作。逐一
     而且springmodules+ common-validator已经提供了默认的几种Validator和在XML节点配置默认注入的框架，只有自己写了特别的validator，并且不希望使用common-validator框架来定义时才像第四步那样使用BaseController的addValidator函数加入新的validator。

2.Binder
     一般由ServletRequestDataBinder完成Bind的工作。与其他框架自动绑定FormBean不同，Spring里需要手工调用Binder.

     但因为日期格式不固定, Binder并没有预先包含Date的Propertity Editor。 另外数字类的Editor默认不允许字符串为空，这些都需要初始化设置。

     在Multi-action体系中,有initBinder()的callBack函数：

        SimpleDateFormat dateFormat = new SimpleDateFormat(DateUtil.getDatePattern());
        binder.registerCustomEditor(Date.class, new CustomDateEditor(dateFormat, true));
        binder.registerCustomEditor(Integer.class, new CustomNumberEditor(Integer.class, true));
        binder.registerCustomEditor(Double.class, new CustomNumberEditor(Double.class, true));
   createBinder的另一个callBack函数是getCommandName()，getCommandName将用于在页面用<spring:bind>绑定错误信息时的标识，baseController默认定为首字母小写的类名。

3.Validator
     Validator的客户端和服务器端方案用common validator和spring moudles里的集成 。

4.Bind and Validate出错处理
    Bind and Validate出错，一般会重新跳回输入页面，在页头以如下代码显示错误信息，并重新绑定所有数据：

<%@ taglib prefix="spring" uri="http://www.springframework.org/tags" %>

<c:iftest="${book!=null}">
    <spring:bind path="book.*">
        <c:if test="${not empty status.errorMessages}"><  BR>            <div class="error">
                <c:forEach var="error" items="${status.errorMessages}">
                    ${error}<br/>
                </c:forEach>
            </div>
        </c:if>
    </spring:bind>
</c:if>

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xmlns:p="http://www.springframework.org/schema/p" xmlns:context="http://www.springframework.org/schema/context"
  xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
    http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-2.5.xsd">

 <!-- 对com.founder.action包中的所有类进行扫描，以完成Bean创建和自动依赖注入的功能 -->
 <context:component-scan base-package="com.founder.action"/>
 
<!-- 启动Spring MVC的注解功能，完成请求和注解POJO的映射 -->
 <bean class="org.springframework.web.servlet.mvc.annotation.AnnotationMethodHandlerAdapter"/>
 
<!--把请求的URL映射到Controller的name上面 -->
 <bean class="org.springframework.web.servlet.mvc.support.ControllerClassNameHandlerMapping"/> 
  
 <!-- 对模型视图名称的解析，即在模型视图名称添加前后缀-->
 <bean id="viewResolver" class="org.springframework.web.servlet.view.InternalResourceViewResolver">
  <property name="viewClass">
   <value>org.springframework.web.servlet.view.JstlView</value>
  </property>
  <property name="prefix">
     <value>/jsp/</value>
  </property>
  <property name="suffix">
   <value>.jsp</value>
  </property>
 </bean>

</beans>

package com.founder.action;

import org.springframework.stereotype.Controller;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.servlet.mvc.multiaction.MultiActionController;

@Controller
@RequestMapping
public class HelloController{
 @RequestMapping
 public String world(){
  String name = "Eric";
  System.out.println("name is = " + name);
  return "hello";
 }
 
 @RequestMapping
 public String test() {
  String name = "test";
  System.out.println("name is = " + name);
  return "test";
 }
 
}

Kerberos协议主要用于计算机网络的身份鉴别(Authentication), 其特点是用户只需输入一次身份验证信息就可以凭借此验证获得的票据(ticket-granting ticket)访问多个服务，即SSO(Single Sign On)。由于在每个Client和Service之间建立了共享密钥，使得该协议具有相当的安全性。

条件

先来看看Kerberos协议的前提条件：

如下图所示，Client与KDC， KDC与Service 在协议工作前已经有了各自的共享密钥，并且由于协议中的消息无法穿透防火墙，这些条件就限制了Kerberos协议往往用于一个组织的内部， 使其应用场景不同于X.509 PKI。

过程

Kerberos协议分为两个部分：

1 . Client向KDC发送自己的身份信息，KDC从Ticket Granting Service得到TGT(ticket-granting ticket)， 并用协议开始前Client与KDC之间的密钥将TGT加密回复给Client。

此时只有真正的Client才能利用它与KDC之间的密钥将加密后的TGT解密，从而获得TGT。

（此过程避免了Client直接向KDC发送密码，以求通过验证的不安全方式）

2. Client利用之前获得的TGT向KDC请求其他Service的Ticket，从而通过其他Service的身份鉴别。

 Kerberos协议的重点在于第二部分，简介如下：

1．    Client将之前获得TGT和要请求的服务信息(服务名等)发送给KDC，KDC中的Ticket Granting Service将为Client和Service之间生成一个Session Key用于Service对Client的身份鉴别。然后KDC将这个Session Key和用户名，用户地址（IP），服务名，有效期, 时间戳一起包装成一个Ticket(这些信息最终用于Service对Client的身份鉴别)发送给Service， 不过Kerberos协议并没有直接将Ticket发送给Service，而是通过Client转发给Service.所以有了第二步。

2．    此时KDC将刚才的Ticket转发给Client。由于这个Ticket是要给Service的，不能让Client看到，所以KDC用协议开始前KDC与Service之间的密钥将Ticket加密后再发送给Client。同时为了让Client和Service之间共享那个秘密(KDC在第一步为它们创建的Session Key)， KDC用Client与它之间的密钥将Session Key加密随加密的Ticket一起返回给Client。

3．    为了完成Ticket的传递，Client将刚才收到的Ticket转发到Service. 由于Client不知道KDC与Service之间的密钥，所以它无法算改Ticket中的信息。同时Client将收到的Session Key解密出来，然后将自己的用户名，用户地址（IP）打包成Authenticator用Session Key加密也发送给Service。

4．    Service 收到Ticket后利用它与KDC之间的密钥将Ticket中的信息解密出来，从而获得Session Key和用户名，用户地址（IP），服务名，有效期。然后再用Session Key将Authenticator解密从而获得用户名，用户地址（IP）将其与之前Ticket中解密出来的用户名，用户地址（IP）做比较从而验证Client的身份。

5．    如果Service有返回结果，将其返回给Client。

总结

概括起来说Kerberos协议主要做了两件事

1．    Ticket的安全传递。

2．    Session Key的安全发布。

再加上时间戳的使用就很大程度上的保证了用户鉴别的安全性。并且利用Session Key，在通过鉴别之后Client和Service之间传递的消息也可以获得Confidentiality(机密性), Integrity(完整性)的保证。不过由于没有使用非对称密钥自然也就无法具有抗否认性，这也限制了它的应用。不过相对而言它比X.509 PKI的身份鉴别方式实施起来要简单多了。

推荐资料：

Kerberos的原理

Kerberos: An Authentication Service for Computer Networks

Web Services Security系列文章 

import Java.text.SimpleDateFormat;
import Java.util.TimeZone;

import org.hibernate.SessionFactory;
import org.springframework.test.AbstractTransactionalDataSourceSpringContextTests;

/**
 * This class is the base class of all the tests,
 * we can use the dependency injection functionality of spring in all the tests,
 * and the default transaction mode is rollback, so we don't need to write special code to restore data after calling some methods affected database data.
 *
 * @author Rui Zhou, Copyright © 2008 foundersoftware. All Rights Reserved.
 * @version 1.00, 2008-03-22 15:46
 */
public abstract class SpringTestCaseBase extends AbstractTransactionalDataSourceSpringContextTests {
 
 protected SimpleDateFormat sdf;
 
 public SpringTestCaseBase() {
  // query the protected variables to implement denpendency injection automatically,
  // so we don't need to write settor and gettor methods anymore.
  this.setPopulateProtectedVariables(true);
  
  sdf = new SimpleDateFormat("yyyy-MM-dd");
  sdf.setTimeZone(TimeZone.getDefault());
 }
 
 protected String[] getConfigLocations() {
  return new String[] { "file:WebRoot/WEB-INF/applicationContext*.xml"};
    }
 
 protected void flushSession(){
  SessionFactory sessionFactory = (SessionFactory)applicationContext.getBean("sessionFactory");  
        sessionFactory.getCurrentSession().flush();
    }
}

WebApplicationContext webApplicationContext = WebApplicationContextUtils.getWebApplicationContext(request.getSession().getServletContext()); 

由于spring是注入的对象放在ServletContext中的，所以可以直接在ServletContext取出WebApplicationContext 对象：

WebApplicationContext webApplicationContext = (WebApplicationContext) servletContext.getAttribute(WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE);

事实上WebApplicationContextUtils.getWebApplicationContext方法就是使用上面的代码实现的，建议使用上面上面的静态方法 

q      void delete(Object entity)：删除指定持久化实例

q      deleteAll(Collection entities)：删除集合内全部持久化类实例

q      find(String queryString)：根据HQL查询字符串来返回实例集合

q      findByNamedQuery(String queryName)：根据命名查询返回实例集合

q      get(Class entityClass, Serializable id)：根据主键加载特定持久化类的实例

q      save(Object entity)：保存新的实例

q      saveOrUpdate(Object entity)：根据实例状态，选择保存或者更新

q      update(Object entity)：更新实例的状态，要求entity是持久状态

q      setMaxResults(int maxResults)：设置分页的大小

1. public interface GenericManager<T, PK extends Serializable> {   
2.   
3. public List<T> getAll();   
4.   
5. public T get(PK id);   
6.   
7. .......基本的CRUD方法   
8.   
9. }  

1. public class GenericManagerImpl<T, PK extends Serializable> implements GenericManager<T, PK> {   
2.   
3. protected BaseGenericHibernateDAO<T, PK> baseGenericHibernateDAO;   
4.   
5. public GenericManagerImpl(BaseGenericHibernateDAO<T, PK> baseGenericHibernateDAO) {   
6. this.baseGenericHibernateDAO = baseGenericHibernateDAO;   
7. }   
8.   
9. 对应实现上面的接口CRUD方法   
10.   
11. }  

另外，在DAO和service层的代码中，除非是为了异常的转化、重新抛出，否则不要捕捉和处理异常，否则AOP在拦截的时候就不能捕捉到异常，也就不能正确执行回滚。这一点通常很容易被忽视，只有在明白了spring的事务处理机制后，才能领会到。

对于hibernate的异常，spring会包装hibernate的upckecked hibernateException到DAOAccessException，并且抛出，在事务管理层，一旦接收到DAOAccessException就会触发事务的回滚，同时该异常会继续向上层抛出，供上层进一步处理，比如在UI层向用户反馈错误信息等。
在spring的事务管理环境下，使用unckecked exception可以极大地简化异常的处理，只需要在事务层声明可能抛出的异常（这里的异常可以是自定义的unckecked exception体系），在所有的中间层都只是需要简单throws即可，不需要捕捉和处理，直接到最高层，比如UI层再进行异常的捕捉和处理。

• PROPAGATION_REQUIRED--支持当前事务，如果当前没有事务，就新建一个事务。这是最常见的选择。
• PROPAGATION_SUPPORTS--支持当前事务，如果当前没有事务，就以非事务方式执行。
• PROPAGATION_MANDATORY--支持当前事务，如果当前没有事务，就抛出异常。
• PROPAGATION_REQUIRES_NEW--新建事务，如果当前存在事务，把当前事务挂起。
• PROPAGATION_NOT_SUPPORTED--以非事务方式执行操作，如果当前存在事务，就把当前事务挂起。
• PROPAGATION_NEVER--以非事务方式执行，如果当前存在事务，则抛出异常。
• PROPAGATION_NESTED--如果当前存在事务，则在嵌套事务内执行。如果当前没有事务，则进行与PROPAGATION_REQUIRED类似的操作。

不过这里面也有些陷阱:如果你的测试还是会把数据写入了数据库的话,可能是由于你加载的spring配置文件里有多个事务管理器或session工厂,从而导致AbstractTransactionalDataSourceSpringContextTests没有获得正确的TransactionManager或SessionFactory,所以就没能回滚不过这种错误也不太容易犯,因为AbstractTransactionalDataSourceSpringContextTests默认按类型组装,如果她发现有多个TransactionManager类型的bean是要报错的,此时你需要调用setAutowireMode(this.AUTOWIRE_BY_NAME);使其按名称组装。

另外值得注意的是，使用MYSQL时候表的类型选择。例如

CREATE TABLE `myisam` (
  `id` int(11) NOT NULL auto_increment,
  `name` varchar(100) default NULL,
  `content` text,
  PRIMARY KEY  (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=gbk;
这时候应该把类型改为InnoDB。

MySQL存储引擎包括处理事务安全表的引擎和处理非事务安全表的引擎：· MyISAM管理非事务表。它提供高速存储和检索，以及全文搜索能力。MyISAM在所有MySQL配置里被支持，它是默认的存储引擎，除非你配置 MySQL默认使用另外一个引擎。 ·MEMORY存储引擎提供“内存中”表。MERGE存储引擎允许集合将被处理同样的MyISAM表作为一个单独的表。就像MyISAM一样， MEMORY和MERGE存储引擎处理非事务表，这两个引擎也都被默认包含在MySQL中。 释：MEMORY存储引擎正式地被确定为HEAP引擎。· InnoDB和BDB存储引擎提供事务安全表。BDB被包含在为支持它的操作系统发布的MySQL-Max二进制分发版里。InnoDB也默认被包括在所 有MySQL 5.1二进制分发版里，你可以按照喜好通过配置MySQL来允许或禁止任一引擎。·EXAMPLE存储引擎是一个“存根”引擎，它不做什么。你可以用这个 引擎创建表，但没有数据被存储于其中或从其中检索。

 <bean id="rememberMeServices" class="org.acegisecurity.ui.rememberme.TokenBasedRememberMeServices">
  <property name="userDetailsService" ref="userDetailsService"/>
  <property name="key" value="changeThis"/>
 </bean>

12.authenticationManager配置

 <bean id="authenticationManager" class="org.acegisecurity.providers.ProviderManager">
  <property name="providers">
   <list>
    <ref local="daoAuthenticationProvider"/>
    <bean class="org.acegisecurity.providers.anonymous.AnonymousAuthenticationProvider">
     <property name="key" value="changeThis"/>
    </bean>
    <bean class="org.acegisecurity.providers.rememberme.RememberMeAuthenticationProvider">
     <property name="key" value="changeThis"/>
    </bean>
   </list>
  </property>
 </bean>

13.daoAuthenticationProvider配置

 <bean id="daoAuthenticationProvider" class="org.acegisecurity.providers.dao.DaoAuthenticationProvider">
  <property name="userDetailsService" ref="userDetailsService"/>
  <property name="userCache">
   <bean class="org.acegisecurity.providers.dao.cache.EhCacheBasedUserCache">
    <property name="cache">
     <bean class="org.springframework.cache.ehcache.EhCacheFactoryBean">
      <property name="cacheManager">
       <bean class="org.springframework.cache.ehcache.EhCacheManagerFactoryBean">
        <property name="configLocation" value="classpath:ehcache.xml"/>
       </bean>
      </property>
      <property name="cacheName" value="userCache"/>
     </bean>
    </property>
   </bean>
  </property>
 </bean>

14.methodSecurityInterceptor配置
 
 <bean id="methodSecurityInterceptor" class="org.acegisecurity.intercept.method.aopalliance.MethodSecurityInterceptor">
  <property name="authenticationManager" ref="authenticationManager"/>
  <property name="accessDecisionManager" ref="accessDecisionManager"/>
  <property name="objectDefinitionSource">
    <value>
     com.rain.wsh.service.IUserService.get*=IS_AUTHENTICATED_ANONYMOUSLY
      com.rain.wsh.service.IUserService.create*=IS_AUTHENTICATED_ANONYMOUSLY
      com.rain.wsh.service.IUserService.update*=IS_AUTHENTICATED_ANONYMOUSLY
      com.rain.wsh.service.IUserService.delete*=IS_AUTHENTICATED_ANONYMOUSLY 
   </value>
  </property>
 </bean>

15.loggerListener配置

 <!-- This bean is optional; it isn't used by any other bean as it only listens and logs -->
 <bean id="loggerListener" class="org.acegisecurity.event.authentication.LoggerListener"/>

注:userDetailsService定义为:
<bean id="userDetailsService" class="com.rain.wsh.service.impl.UserDetailsServiceImpl"/>

package com.rain.wsh.service.impl;

import org.acegisecurity.userdetails.UserDetails;
import org.acegisecurity.userdetails.UserDetailsService;
import org.acegisecurity.userdetails.UsernameNotFoundException;
import org.springframework.dao.DataAccessException;

import com.rain.wsh.dao.IUserDAO;

public class UserDetailsServiceImpl implements UserDetailsService {
 private final Logger log = Logger.getLogger(getClass());
 
 private IUserDAO userDAO;
 
 /**
  * @return the userDAO
  */
 public IUserDAO getUserDAO() {
  return userDAO;
 }

 /**
  * @param userDAO the userDAO to set
  */
 public void setUserDAO(IUserDAO userDAO) {
  this.userDAO = userDAO;
 }
 
 /*
  * (non-Javadoc)
  * @see org.acegisecurity.userdetails.UserDetailsService#loadUserByUsername(java.lang.String)
  */
 public UserDetails loadUserByUsername(String userName) throws UsernameNotFoundException, DataAccessException {
  
  UserDetails user = userDAO.getUserByName(userName);
  if (user == null) {
   log.error("The user was not found:" + userName);
   throw new UsernameNotFoundException("The user was not found:" + userName);
  }
  return user;
 }

}

注意user必须实现Serializable, UserDetails