SPRING AOP 2.0 in Font

Generate Denso QR Bar Code in Font SPRING AOP 2.0

We ve already covered how to use AnnotationAwareAspectJAutoProxyCreator in the Spring container to enable auto-proxy creation, which is a requirement to use @AspectJ-style aspects with Spring AOP In this section, we ll discuss another way of enabling auto-proxy creation. We ll also explain . how Spring AOP 2.0 decides which proxy types to use, and we ll shed some more light on how Spring AOP decides to create proxy objects for beans.

The other way of enabling auto-proxy creation is to use the Spring AOP XML Schema and its <aop:aspectj-autoproxy> tag. Listing 4-13 shows a Spring XML configuration file that uses the AOP XML Schema and the aop namespace. Listing 4-13. Using Spring s AOP XML Schema to Enable @AspectJ-Style Aspects in the Spring Container < 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" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://www.springframework.org/schema/aop http://www.springframework.org/schema/aop/spring-aop.xsd"> <aop:aspectj-autoproxy/> </beans> Using the <aop:aspectj-autoproxy> XML tag has an advantage: if you accidentally define this tag more than once in your Spring configuration, no harm is done. If you configure the AnnotationAwareAspectJAutoProxyCreator more than once in your configuration, auto-proxy creation will occur twice for each bean something you want to avoid. Otherwise, both approaches have exactly the same effect: auto-proxy creation is enabled for the entire Spring container.

The proxy type selection strategy in Spring AOP 2.0 has changed slightly from the previous version of Spring AOP Since version 2.0, JDK proxy objects will be created for target objects that implement . at least one interface. For target objects that implement no interfaces, CGLIB proxy objects will be created. You can force the creation of CGLIB proxies for all target classes by setting the proxy-targetclass option to true: <aop:aspectj-autoproxy proxy-target-class="true"/> Forcing the use of CGLIB proxy objects is required when at least one object for which a proxy object is created in the Spring container implements one or more interfaces, but is used as the class type by its callers. In this case, a JDK proxy object that implements only the interfaces would not be type-compatible for certain callers. Proxy objects created by CGLIB remain type-compatible with the target object. In all other cases, you can safely leave the proxy-target-class option disabled.

In the example in Listing 4-5, we configured three beans to be loaded by the Spring container. A proxy object was created for only one of them. Let s review the role of each bean definition in Listing 4-5: AnnotationAwareAspectJAutoProxyCreator: This class is responsible for auto-proxy creation. There s no need to create a proxy object for this bean, since it s not called by the application itself. Instead, it will enhance the bean life cycle for all other beans in the container. MessagePrintingAspect: This is a regular Java class and an @AspectJ-style aspect. No proxy object is created for this bean, since it s also not called by the application. Instead, it embeds advices and pointcuts that will determine for which other beans in the container proxy objects will be created. DefaultTournamentMatchManager: This class is part of the application logic. What s more, it has a join point that is matched by the pointcut in the MessagePrintingAspect: its startMatch() method. Because at least one join point is matched, a proxy object will be created and will replace the original bean in the container during the bean life cycle. So once the bean life cycle has been completed successfully for the tournamentMatchManager bean, the container will return a proxy object with advice and its target object. So let s wrap up the rules for auto-proxy creation in the Spring container based on the example: Beans that implement the org.springframework.beans.factory.BeanPostProcessor or org.springframework.beans.factory.BeanFactoryPostProcessor interfaces will never be proxied. AnnotationAwareAspectJAutoProxyCreator implements the BeanPostProcessor interface, which allows it to enhance the bean life cycle for beans created by the Spring container. @AspectJ-style aspects, beans that implement the org.springframework.aop.Advisor or org.springframework.aop.Pointcut interfaces, and beans that implement any of the classic Spring AOP advice-type interfaces discussed in the previous chapter are excluded from autoproxy creation because they have infrastructural roles. All other beans that are created by the Spring container are eligible for auto-proxy creation. During the life cycle of each bean created by the Spring container both singleton and prototype beans the container will ask all aspects and advisors found in the container if one or more of the bean join points are matched by one of their pointcuts. If there is at least one match, a proxy object will be created for the bean and will replace that bean. The proxy object will have all the advice embedded for all join points that were matched. To fully understand the last rule, you need to know how join points will be matched by any given pointcut. If you look back at the example and its pointcut in Listing 4-3, it s obvious that only methods named startMatch() will be matched. Later in this chapter, in the Working with Pointcuts section, we ll discuss other pointcuts that select join points in specific ways.