In addition to the aspect annotated with @Configurable, spring-aspects.jar contains an AspectJ aspect that can be used to manage Spring transactions for types and methods annotated with the @Transactional annotation. It is primarily intended for users who want to use the Spring Framework transaction support outside of the Spring container.

The Aspect that interprets @Transactional annotations is the AnnotationTransactionAspect. When using this aspect, you need to annotate the implementation class (or the methods within that class, or both), not the interface (if any) that the class implements. AspectJ follows the Java rule that interface annotations are not inherited.

The @Transactional annotation for a class defines the default transaction semantics for performing any public operation on the class.

The @Transactional annotation on a method in a class overrides the default transaction semantics specified by the class annotation (if present). Methods of any visibility can be annotated, including private methods. Annotating non-public methods directly is the only way to obtain transaction delimitation for the execution of such methods.

Starting with Spring Framework 4.2, spring-aspects provides a similar aspect that offers exactly the same capabilities to the standard annotationjavax.transaction.Transactional. For more information, check out JtaAnnotationTransactionAspect.

For AspectJ programmers who want to use Spring's configuration and transaction management support but don't want (or can't) use annotations, spring-aspects.jar also contains abstract aspects that can be extended to specify your own slice definitions. For more information, see the AbstractBeanConfigurerAspect and AbstractTransactionAspect sources. For example, the following snippet shows how you can write an aspect to configure all instances of objects defined in a domain model using prototype bean definitions that correspond to fully qualified class names:

public aspect DomainObjectConfiguration extends AbstractBeanConfigurerAspect {
    public DomainObjectConfiguration() {
        setBeanWiringInfoResolver(new ClassNameBeanWiringInfoResolver());
    }
    // creating a new bean (any object in the domain model)
    protected pointcut beanCreation(Object beanInstance) :
        initialization(new(..)) &&
        CommonPointcuts.inDomainModel() &&
        this(beanInstance);
}

Configuring AspectJ aspects using IoC in SpringC

When using aspects from AspectJ in Spring applications, it is natural to want and expect to be able to configure such aspects using Spring. The AspectJ runtime itself is responsible for creating aspects, and the means for configuring aspects created in AspectJ via Spring depends on the AspectJ instantiation model (per-xxx expression) used by the aspect.

Most AspectJ aspects are single aspects. Configuring these aspects is extremely simple. You can normally create a bean definition that references an aspect type and include the factory-method="aspectOf" bean attribute in it. This will ensure that Spring gets an instance of the aspect by requesting it from AspectJ rather than trying to instantiate it itself. The following example shows how to use the factory-method="aspectOf" attribute:

<bean id="profiler" class="com.xyz.profiler.Profiler"
        factory-method="aspectOf"> 
    <property name="profilingStrategy" ref="jamonProfilingStrategy"/>
</bean>
  1. Pay attention to the factory-method="aspectOf" attribute

Aspects that are not singletons are more difficult to configure. However, this can be done by creating prototype bean definitions and using the @Configurable annotation support from spring-aspects.jar to configure aspect instances after they are created by the AspectJ runtime .

If there are a number of @AspectJ aspects that you need to bind using AspectJ (for example, using load-time binding for domain model types), and other @AspectJ aspects that you need to use in Spring AOP, and all of these aspects are configured in Spring, you need to tell Spring AOP's @AspectJ autoproxy support which subset of the @AspectJ aspects defined in the configuration should be used for autoproxy. This can be done using one or more <include/> elements inside the <aop:aspectj-autoproxy/> declaration. Each <include/> element defines a name pattern, and only those beans whose names match at least one of the patterns are used to configure auto-proxy in Spring AOP. The following example shows how to use <include/> elements:

<aop:aspectj-autoproxy>
    <aop:include name="thisBean"/>
    <aop:include name="thatBean"/>
</aop:aspectj-autoproxy>
Don't be fooled by the name of the <aop:aspectj-autoproxy/> element. Using it causes a proxy to be created in Spring AOP. In this case, the @AspectJ style is used to declare aspects, but the AspectJ runtime is not used.