Section 6.3. Using an Autoproxy

6.3. Using an Autoproxy

So far, you've explicitly and manually created each proxy. Spring also has the ability to automatically create a proxy, or autoproxy. The goal of the autoproxy is to apply the same signature to a number of methods. In this lab, you'll use an autoproxy to attach profiling code to all of the classes in the application.

6.3.1. How do I do that?

Spring 1.1 lets you do autoproxying in two ways. You can:

• Specify a configuration and apply it to named beans context.

• Use source-level metadata (added to the JDK in Java 5, but available through Apache Commons annotations today).

In this example, you're going to be proxying named beans. As before, you'll first need some advice. Example 6-7 shows around advice that prints profiling statements before and after Spring enters a method.

Example 6-7. ProfilingInterceptory.java

public class ProfilingInterceptor implements MethodInterceptor{     public Object invoke(MethodInvocation methodInvocation)             throws Throwable {         long start = System.currentTimeMillis( );         Object results = methodInvocation.proceed( );         long end = System.currentTimeMillis( );         System.out.println("Method: " +             methodInvocation.getMethod( ).getName( ) + " took " +            (end - start) + " ms.");         return results;     } }

Next, configure it. Don't specify a single target, but a regular expression. Spring will apply the advice to all of the beans that match. Specify the autoproxy, the advice, and the targets (Example 6-8).

Example 6-8. RentABike-servlet.xml

<bean name="profilerAround"     /> <bean name="profilingAutoProxy" >             <property name="beanNames"><value>rentaBike*</value></property>    <property name="interceptorNames">       <list>          <value>profilerAround</value>       </list>    </property> </bean>

Now, when you run the application on std.out console, you can see that the application tells you when it enters or leaves a given method and how much time the method took to execute (Example 6-9).

Example 6-9. Standard out from running application

Entered toString Method: toString took 0 ms. Entered isSingleton Method: isSingleton took 0 ms. Entered getObject Method: getObject took 0 ms. Entered getObject Method: getObject took 0 ms. Entered getObject Method: getObject took 0 ms. Entered getObject Method: getObject took 0 ms. Entered getObject Method: getObject took 0 ms. Entered getObject Method: getObject took 0 ms. Entered saveBike Method: saveBike took 31 ms. Entered getBike Method: getBike took 78 ms. Entered deleteBike Method: deleteBike took 62 ms. Entered getBikes Method: getBikes took 47 ms.

6.3.2. What just happened?

This example has two major differences from the previous one: we're working on multiple beans, and we're using a different type of advice. Let's take a closer look.

Drill down on the interceptor itself first. You'll notice that the MethodInterceptor advice, inside the invoke method, does some work, calls proceed, and then does more work. Drill down to the call to proceed in our interceptor. That method calls the next interceptor in the chain, or the target method if it's at the last interceptor in the chain. You have a whole lot of flexibility here:

• You can do some work before the proceed( ), like our caching of the start time of the method. That code will execute before the target method.

• You can do some work after the proceed( ), but before the return. That code will execute after the target method.

• You can decide not to call proceed( ). In this case, the target method will not execute.

• Your code can fire an exception, changing the flow of control. In your exception, you may or may not decide to call proceed( ).

Otherwise, this kind of advice works just like the others. So which kind of advice should you use? Spring founder Rod Johnson suggests that you use the weakest type of advice that will work for you.

There's another difference between this example and the last: the target. You're proxying multiple targets. After Spring loads a context, it takes a post-processing pass through the beans of the context. In this pass, Spring applies this proxy definition to all of the beans in the context. It first decides if the bean matches the specified target. If it does, it creates the specified proxy.