Configuraion for Spring transaction management

Trying to understand the declarative transaction management of Spring. The following is from the document of Spring Release 3.2.1.

<!-- from the file 'context.xml' -->
<?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:aop="http://www.springframework.org/schema/aop"
 xmlns:tx="http://www.springframework.org/schema/tx"
 xsi:schemaLocation="
     http://www.springframework.org/schema/beans
     http://www.springframework.org/schema/beans/spring-beans.xsd
http://www.springframework.org/schema/tx
     http://www.springframework.org/schema/tx/spring-tx.xsd
     http://www.springframework.org/schema/aop
     http://www.springframework.org/schema/aop/spring-aop.xsd">

 <!-- this is the service object that we want to make transactional -->
 <bean id="fooService" class="x.y.service.DefaultFooService" />
 <!-- the transactional advice (what 'happens'; see the <aop:advisor/> bean 
  below) -->

 <tx:advice id="txAdvice" transaction-manager="txManager">
  <!-- the transactional semantics... -->
  <tx:attributes>
   <!-- all methods starting with 'get' are read-only -->
   <tx:method name="get*" read-only="true" />
   <!-- other methods use the default transaction settings (see below) -->
   <tx:method name="*" />
  </tx:attributes>
 </tx:advice>

 <!-- ensure that the above transactional advice runs for any execution of 
  an operation defined by the FooService interface -->
 <aop:config>
  <aop:pointcut id="fooServiceOperation"
   expression="execution(* x.y.service.FooService.*(..))" />
   <aop:advisor advice-ref="txAdvice" pointcut-ref="fooServiceOperation" />
 </aop:config>

 <!-- don't forget the DataSource -->
 <bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource" destroy- method="close">
  <property name="driverClassName" value="oracle.jdbc.driver.OracleDriver" />
  <property name="url" value="jdbc:oracle:thin:@rj-t42:1521:elvis" />
  <property name="username" value="scott" />
  <property name="password" value="tiger" />
 </bean>

 <!-- similarly, don't forget the PlatformTransactionManager -->
 <bean id="txManager"
  class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
  <property name="dataSource" ref="dataSource" />
 </bean>
 <!-- other <bean/> definitions here -->
</beans>

The central part is the advisor in the <aop:config> section. It takes two arguments "advice-ref" and "pointcut-ref". Roughly speaking, an advisor advices "someone" to do "something". Here pointcut-ref is that "someone". And advice-ref is that "something". Basically what it says is to apply the advices given in "advice-ref" to those classes and/or methods defined in "pointcut-ref". So actually it is a generic thing of AOP. It is not just for transaction management.

A common requirement is to make an entire service layer transactional.The best way to do this is simply to change the pointcut expression to match any operation in your service layer. For example:

<aop:config>
 <aop:pointcut id="fooServiceMethods" expression="execution(* x.y.service.*.*(..))" />
 <aop:advisor advice-ref="txAdvice" pointcut-ref="fooServiceMethods" />
</aop:config>

In this example it is assumed that all your service interfaces are defined in the x.y.service package.

Spring's declarative transaction support is enabled via AOP proxies. The AOP proxy uses a TransactionInterceptor. In the Spring Framework, an AOP proxy will be a JDK dynamic proxy or a CGLIB proxy. So underneath, the implementation uses interceptor. You can actually configure org.springframework.transaction.interceptor.TransactionInterceptor directly in XML for transaction management without using AOP.

AOP expression

Below is from Spring document (see the Reference).

Spring AOP users are likely to use the execution pointcut designator the most often. The format of an execution expression is:

execution(modifiers-pattern? ret-type-pattern declaring-type-pattern? name-pattern(param-pattern)
throws-pattern?)

All parts except the returning type pattern (ret-type-pattern in the snippet above), name pattern, and parameters pattern are optional. The returning type pattern determines what the return type of the method must be in order for a join point to be matched. Most frequently you will use * as the returning type pattern, which matches any return type. A fully-qualified type name will match only when the method returns the given type. The name pattern matches the method name. You can use the * wildcard as all or part of a name pattern. The parameters pattern is slightly more complex: () matches a method that takes no parameters, whereas (..) matches any number of parameters (zero or more). The pattern (*) matches a method taking one parameter of any type, (*,String) matches a method taking two parameters, the first can be of any type, the second must be a String. Consult the Language Semantics section of the AspectJ Programming Guide for more information.

Some examples of common pointcut expressions are given below.

• the execution of any public method:
  execution(public * *(..))
• the execution of any method with a name beginning with "set":
  execution(* set*(..))
• the execution of any method defined by the AccountService interface:
  execution(* com.xyz.service.AccountService.*(..))
• the execution of any method defined in the service package:
  execution(* com.xyz.service.*.*(..))
• the execution of any method defined in the service package or a sub-package:
  execution(* com.xyz.service..*.*(..))

Rollback Configuration

Spring by default marks a transaction for rollback when a runtime exception is thrown. However you can customize the behavior to let the rollback happen for checked exceptions. The following is an example.

<tx:advice id="txAdvice" transaction-manager="txManager">
 <tx:attributes>
  <tx:method name="get*" read-only="true" rollback-for="CheckedException1, CheckedException2" />
  <tx:method name="*" />
 </tx:attributes>
</tx:advice>

Note that you use comma-delimited expression in the value for rollback-for. There is another attribute no-rollback-for to mark exceptions that should not trigger rollback.

Using transaction annotation

You can annotate the class with @Transactional. The following is from Spring doc.

// the service class that we want to make transactional
@Transactional
public class DefaultFooService implements FooService {
 Foo getFoo(String fooName);
 Foo getFoo(String fooName, String barName);
 void insertFoo(Foo foo);
 void updateFoo(Foo foo);
}

<!-- from the file 'context.xml' -->
<?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:aop="http://www.springframework.org/schema/aop"
 xmlns:tx="http://www.springframework.org/schema/tx"
 xsi:schemaLocation="
     http://www.springframework.org/schema/beans
     http://www.springframework.org/schema/beans/spring-beans.xsd
     http://www.springframework.org/schema/tx
     http://www.springframework.org/schema/tx/spring-tx.xsd
     http://www.springframework.org/schema/aop
     http://www.springframework.org/schema/aop/spring-aop.xsd">
     
 <!-- this is the service object that we want to make transactional -->
 <bean id="fooService" class="x.y.service.DefaultFooService" />
 
 <!-- enable the configuration of transactional behavior based on annotations -->
 <tx:annotation-driven transaction-manager="txManager" />
 
 <!-- a PlatformTransactionManager is still required -->
 <bean id="txManager"
  class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
  <!-- (this dependency is defined somewhere else) -->
  <property name="dataSource" ref="dataSource" />
 </bean>
 <!-- other <bean/> definitions here -->
</beans>

Comparing this annotation method against the AOP XML method, you may ask what are the things corresponding to "someone" and "something" of the advisor? The annotation seems to solve the problems altogether in a completely different way. The annotation location indicates the "someone" part. And the annotation name itself indicates that transaction management needs to be carried out, which is "something".

References

1. http://docs.spring.io/spring/docs/3.2.1.RELEASE/spring-framework-reference/pdf/spring-framework-reference.pdf

Notes on using the Spring annotation

Assuming that Spring 3.2.1.Release or above is used in the following notes.

1. You can use <context:annotation-config/>. It will look for annotations on the properties and methods of a bean, but not the bean class itself.
2. You use <context:component-scan base-package="org.example" /> to automatically detect classes and register bean definitions. The use of this implicitly enables the functionality of <context:annotation-config>. Also be aware of the following.
   • When <context:component-scan/> is used, the java classes involved need to be annotated with @Component, @Service, etc. Otherwise they would not be recognized.
   • The annotated classes are put into the Spring IoC container. You need to get a bean from this container to get the beans with all the injected properties. Outside this container, the instances of those classes are just plain instances. The annotations have no effect on them.
   • An interesting case is about the servlet. Below is an example.

             @Component
             public class myServlet extends HttpServlet {
                private @Autowired FooService fooService;
             }
             

     Even though this class is annotated with @Component, the fooService will still be null when this servlet is called in the web application. I think this is because the servlet instance used here is from the Web container. It is NOT from the Spring IoC container. The Spring IoC container may have a copy of this class with fooService injected. But it is not used. So how to still use annotation in a servlet? First of all, the @Component annotation can be removed on servlet. It is not needed since the servlets follow the standard Web container life cycle. The servlet that gets called is from the Web container instead of Spring IoC container. Inside the servlet, you can make annotation work by overriding the init() method as in the following:

        public void init(ServletConfig config) throws ServletException {
           super.init(config);
           SpringBeanAutowiringSupport.processInjectionBasedOnServletContext(this,config.getServletContext());
       }
     

     Or you can just declare fooService as a plain non-annotated field:

           private FooService fooService;
         

     Then in the code inside the servlet, you can get this object from Spring IoC container as below:

           ApplicationContext applicationContext = WebApplicationContextUtils.getWebApplicationContext(this.getServletContext());
     
           FooService service = (FooService)applicationContext.getBean("fooService");
       

3. Annotation injection is performed before XML injection. So the latter configuration will override the former for properties wired through both approaches. You can inject some properties using annotations and other properties using XML. For example, you can have the following:

     public class Foo{
       private @Autowired  Bar bar;
       private DataSource dataSource;
   
     }
   
   

   You can use XML to inject dataSource.
4. You can use @Configuration class so no XML configuration file is needed. But a cost is that you have to create new java classes with the @Configuration annotation.
5. To use a @Configuration class, you use AnnotationConfigApplicationContext to include the class. Say that AppConfig is annotated with @Configuration, you can use the following when the application is started.

        public static void main(String[] args){
            ApplicationContext ctx = new AnnotationConfigApplicationContext(AppConfig.class);
            MyService myService = ctx.getBean(MyService.class);
            myService.doStuff();
        }
   

   AnnotationConfigApplicationContext actually is more versatile than that. It can also be used to scan annotated classes as this: ctx.scan("com.sample"). For more information, see Spring documentation.

   In the Web application, you use AnnotationConfigWebApplicationContext. The web.xml file can be configured as below:

     <!-- Configure ContextLoaderListener to use AnnotationConfigWebApplicationContext instead of
           the default XmlWebApplicationContext -->
    <context-param>
        <param-name>contextClass</param-name>
        <param-value>org.springframework.web.context.support.AnnotationConfigWebApplicationContext</param-value>
    </context-param>
    
    <!-- Configuration location must consist of one or more comma- or space-delimited fully-qualified @Configuration classes. 
    Fully-qualified packages may also be specified for component-scanning -->
    <context-param>
     <param-name>contextConfigLocation</param-name>
     <param-value>com.myapp.AppConfig</param-value>
    </context-param>
    
    <listener>
     <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
    </listener>
   

   If you look at the above code snippet, you may wonder how the parameter name "contextClass" is used. It is declared but not referenced anywhere. I think the secret lies in the comment above that parameter. This parameter is implicitly used by the Spring ContextLoaderListener class. As that comment says, ContextLoaderListener uses XmlWebApplicationContext as the contextClass by default. Now we are not using the Spring XML bean definition files, so we change this to AnnotationConfigWebApplicationContext!
6. There are debates about which way is better, annotation or XML? Both actually have their own pros and cons. Spring's @Configuration class support does not aim to be a 100% complete replacement for Spring XML. You can choose to use "XML-centric" way or java "Annotation-centric" way.

References

https://www.mkyong.com/spring3/spring-3-and-jsr-330-inject-and-named-example

http://stackoverflow.com/questions/18387993/spring-jsf-integration-how-to-inject-a-spring-component-service-in-jsf-managed

http://www.beyondjava.net/blog/integrate-jsf-2-spring-3-nicely