Adding interceptors to beans

[elli]

Hi,
We need to wrap java bean methods with CGLIB callbacks. I tried AspectJ and it is very simple and works fine, however the amount of code it executes at runtime is too large for the application.

What it the best place to plug my callbacks and method wrapping code?

Do I have to create a new post processor from scratch, or is there a way to plug into the existing proxy factories and provide the callbacks for a method?

Maybe Bean Factory (can support constructors)?

Ideally, I would like to implement something like this:

public boolean  shouldProxy(Class c);

public Callback getCallback(Method m);

If I have to write a new extension, I would also like to contribute it, for developers that are interested in AOP without performance impact.

Even better, would be a place where I can get the Advice from AspectJ and create my own proxy from it using CGLIB! This will still allow using AspectJ syntax for proxying.

Thanks!

[Marten Deinum]

Why is the executed code to large at runtime? I think the 'performance hit' will also be there if you would invent your own mechanism. I would suggest that you try JdkDynamicProxies instead of cglib proxies, it might performe better.

[karldmoore]

It would also be really useful to understand what it is you're trying to do.

[elli]

Hi,
This is what we try to do:

• If a bean method has an annotation @MyAnnotation, wrap the method with Around Advice.
• Minimal performance impact on runtime calls to the beans.

First implementation was using AspectJ, with point cut:

@Around("@annotation(com.blah.MyAnnotation)") 

Very easy to set up, however performance was very slow. I benchmarked it. The reason as far as I can tell is that when you call the bean method, the proxy tries to assemble the list of aspects dynamically. Just put a breakpoint and see how much code runs when you call the bean method. Quite a lot. I could not find a way to make this assembly static, when the proxy is generated. It all happens at runtime each time the bean method is called.

More details:
http://forum.springframework.org/showthread.php?t=40417

Current implementation is this:

<beans>
  <!-- Enable Spring AOP support -->
  <bean class="org.springframework.aop.framework.autoproxy.DefaultAdvisorAutoProxyCreator">
    <property name="exposeProxy" value="false" />
    <property name="frozen" value="true" />
    <property name="opaque" value="false" />
    <property name="optimize" value="true" />
  </bean>

  <!-- pointcut advisor -->
  <bean class="org.springframework.aop.support.DefaultPointcutAdvisor">
    <property name="pointcut">
      <bean class="...">
      ... 
      </bean>
    </property>
    <property name="advice">
      <bean class="com.blah.MyMethodInterceptor" />
    </property>
  </bean>
</beans> 

Performance is much better. The advice is resolved and configured at load time, and not when you call the bean method.

There is still an overhead of using the aopalliance MethodInterceptor interface and not the CGLIB comparable interface, but this is small comparing to resolving the list of aspects on every bean method call.

The impact on methods that are annotated is ~1:100, and methods that are not annotated in the same bean ~1:10. With AspectJ it was about an order of magnitude slower.

This is acceptable for the application. I think using the CGLIB interceptors directly can improve performance further. However, the major performance impact of dynamic aspect lookups on every method call is solved (verified using debugger). Currently this is sufficient.

If there is a way to use CBLIB directly I would still be interested to know, but its not so important now with the current benchmark results.

Thanks for the interest!

PS. PHP tag makes nice XML color coding

[elli]

Just to bump it up:
I consider this a bug. The aspects can be resolve at load time and computed once, and not on every method call. Unless there is something I am missing here these are all in an XML file that is loaded once, so they can be initiated when the bean is loaded and the proxy is ready to roll.

As a note, DefaultAdvisorAutoProxyCreator does not have this bug. We are talking major performance impact here.

It would also be nice to have an implementation where the interceptor implement the CGLIB interfaces directly and not the abstracted spring interfaces. This may exist but I cannot fine it (or find the extension point to do it myself).

[Marten Deinum]

With proxy based AOP you will always have some kind of performance hit. If you want to have virtually no performance hit you might want to look at loadtime or compile time weaving of your aspects.

With Spring 2.5 that is quite easy to accomplish, with 2.0 it is a little more difficult but also quite doable.

[elli]

Agree, compile time is probably the answer, but it makes development more difficult and requires special tooling for debugging.

As for load time, AspectJ implementation in spring does not do that, so I don’t think it is possible. It calculates the aspects every time you call a method, and not when you get a bean instance from the spring context.

I am in the process of upgrading to spring 2.5, which interestingly invoked another thread