6/5/10

Spring AOP and Reflection Pitfalls

Prologue
This post intents to point out some pitfalls when using spring aop and reflection on the same objects. Moreover, it provides some examples of these pitfalls when combining ServiceMix & Camel with Spring JPA/Hibernate.

The two most common uses of aspect oriented programming with spring are
  • Security
  • Transaction Handling
I found myself having issues when applying those 2 on beans that are accessed using reflection (not in all cases) and below I am going to dig into those issues.

Spring AOP flavors
Spring aop can be used in many different flavors:
  • Compile time weaving 
  • Load time weaving
  • Using dynamic or cglib proxies  (The main focus of this post)
Cglib proxies and reflection
There are many cases where a bean needs to be accessed using reflection. A common case is to use reflection in order to access a private field. 

I could use the following piece of code in order to retrieve the privateProperty value of SomeBean using Reflection like this:
And this would work pretty cool. However, if the someBeanInstance is enhanced using cglib, the code above would break resulting in having a null value in privatePropertyValue.
Spring's Transactional annotation and Reflection
The problem as described above might be pretty obvious, however here is a direct side effect of it that is not that obvious. Let's assume the use of Spring's transactional annotation. A possible set up could be
the bean annotated as transactional could be
If the resource is injected using traditional reflection(as described above), this would eventually result in a Null Pointer Exception, due to the fact that the resource would fail to be injected.
Moreover, the Exception would trigger a transaction rollback and the entity would not be saved.


You might wonder "why would reflection  fail?". The answer is that the cglib proxy is actually a subclass of the proxied object that is created on run-time and thus reflection would fail to find the declared field on the proxy. In order to to make it work, the getDeclared needs to be called upon the super class (but it would break once you removed the aop).


Work around: Spring's ReflectionUtils to the rescue
 Spring provides a class that among others offers a work around for this issue. Here is an example of using Spring's ReflectionUtils on cglib proxies.
Behind the scenes spring will attempt to find the declared field both on the target object(someBean) and all its superclasses. So if someBean is proxied, it will fail to find the declared field on the proxy, but it will succed using its superclass (SomeBean.class).
Real examples using Apache ServiceMix & Camel
I first encountered the issue the first time I attempted to add the transactional annotation on the bean of a ServiceMix's BeanEndpoint. A simplified version of this case is here.
ServiceMix uses reflection (as described above) in order to inject the DeliveryChannel to the MessageExchangeLister and this reproduces the problem.  Unfortunately, a direct solution to this issue would require editing the BeanEndpoint itself (which is not such a bad idea). An other work around would be to use the transactional annotation using compile time weaving. Finally, if none of the above seems appealing, you can always create an other bean that will be annotated as transactional an make calls to that bean from inside the MessageExchangeLister.

Note: The bean endpoint itself uses Spring's ReflectionUtils and it shouldn't encounter this issue, however it still does, due to the fact that the property (in this case the DeliveryChannel) is set on the proxy and not the actual object.

A similar case I encountered was the use of Camel's @RecipientList annotation combined with Spring's @Transactional annotation. I will not get into details about it, since I think that by now its pretty obvious.

Final thoughts
If you get to understand the nature if this issue its not that hard to deal with it. However, I spent a great deal of time trying to identify the root cause.

In most cases you can bypass it by avoiding to proxy the reflection target itself. To do so you only pass a reference of the proxied object to the class that is access using reflection.

From what I read in the forums, it taunts a lot of people and this is why I decided to blog about it. 


I hope you find it useful!

6 comments:

  1. Thanks, this really helped me for using reflection on Hibernate Annotations

    ReplyDelete
  2. Thanks. Glad to find the article. I have the feeling it's a good start to solve my problem. But I'm not quite there.

    My case is similar to yours, but the issue is that in my Proxy my EntiyManager does not get instantiated in my proxy.

    Any ideas?

    Thanks.

    Jochen

    ReplyDelete
  3. @Jochen: In my example the entity manager is not instantiated in the proxy, but it gets injected in it. I would need more details in order to help you further.

    ReplyDelete
  4. @Jocehn: In my example the entity manager is not instantiated in the proxy but it gets injected. I will need more details in order to help you further.

    ReplyDelete
  5. I wasn't able to get correct behavior from ReflectionUtils when trying to invoke a private method on my proxied Spring bean (I got the same errors I got when I didn't use ReflectionUtils); I think that's because although you say "So if someBean is proxied, it will fail to find the declared field on the proxy, but it will succed using its superclass (SomeBean.class)", that is not the case; a Spring bean that is a proxy does not inherit from the class it wraps (though it will implement all interfaces that the wrapped class implements).

    However, I was able to get correct behavior by simply reaching into the proxy and pulling out the target (which is of type SomeBean in your example) and invoking the (no-argument) method against it:

    Method myMethod = SomeBean.class.getDeclaredMethod("myMethod");
    myMethod.setAccessible(true);
    Advised advised = (Advised)someBean;
    SomeBean someBeanTarget = (SomeBean)advised.getTargetSource().getTarget();
    Object result = myMethod.invoke(someBeanTarget);

    ReplyDelete
    Replies
    1. @Tim: You mention that " Spring bean that is a proxy does not inherit from the class it wraps". That is the case when you are using dynamic proxies. In the case of cglib proxies, the proxy is a subclass of the proxies class.

      Delete