Problem with @Cacheable and @Autowired

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Create a @Controller class with @Autowired fields and @Cacheable methods
2. Start a Spring app using that class
3. Check the @Autowired fields

What is the expected output? What do you see instead?
Expect that the @Autowired fields have been initialized.
However, the @Autowired fields are null.

What version of the product are you using? On what operating system?
ehcache-spring-annotations 1.0.5
spring 3.0.2
WinXP

Please provide any additional information below.
I suspect there's a collision between Spring's internal annotation handling and 
what ehcache-spring-annotations is doing. Our app has 
<context:annotation-config/>
<context:component-scan base-package="..."/>
<ehcache:annotation-driven create-missing-caches="true"/>
as well as 
DefaultAnnotationHandlerMapping and AnnotationMethodHandlerAdapter beans

Original issue reported on code.google.com by andy.kri...@gmail.com on 8 Jun 2010 at 3:50

[GoogleCodeExporter]

This is actually a problem with the class being proxied when it should not be. 
I refactored things to an explicit bean declaration in Spring config with 
explicit property wiring using setters (no @Autowired fields). If I use 
@Cacheable on a method in the bean, the class becomes proxied even if 
proxy-target-class is set to false explicitly.

Original comment by andy.kri...@gmail.com on 8 Jun 2010 at 4:14

[GoogleCodeExporter]

Thanks for the report. I'll see if I can find some time to create a unit test 
that reproduces this and then we can see about fixing it.

Original comment by eric.dalquist on 8 Jun 2010 at 11:22

• Changed state: Accepted

[GoogleCodeExporter]

I added a unit test to the trunk code, what will be 1.1.0, and I can't 
reproduce this. @Autowired works both for a class using @Cacheable on the 
interface and on the class.

You can take a look at 
http://code.google.com/p/ehcache-spring-annotations/source/detail?r=430 for the 
changes that add the test.

We should be releasing 1.1.0 next week.

Original comment by eric.dalquist on 11 Jun 2010 at 7:46

• Changed state: Invalid

[GoogleCodeExporter]

Thank you for putting that test together. I don't have a moment right now to 
dig into it but I notice one difference on a quick look - I had annotated the 
field directly, not a setter method. Don't know that that will make a 
difference, but thought I'd mention it all the same.

Original comment by andy.kri...@gmail.com on 11 Jun 2010 at 9:04

[GoogleCodeExporter]

I'll also try 1.1.0 as soon as it's released.

Original comment by andy.kri...@gmail.com on 11 Jun 2010 at 9:05

[GoogleCodeExporter]

Thanks for the clarification. I'll update the test further.

Original comment by eric.dalquist on 11 Jun 2010 at 10:43

• Changed state: Accepted

[GoogleCodeExporter]

I added a bunch of additional autowiring tests:
http://code.google.com/p/ehcache-spring-annotations/source/detail?r=436

Original comment by eric.dalquist on 12 Jun 2010 at 2:45

• Changed state: Invalid

[GoogleCodeExporter]

Are there any fixes for this problem? We are running in the same problems in 
our project with spring 3.0.5 and ehcache-spring-1.1 and I am really stuck 
because we do not want to change the implementation to an explicit bean 
declaration. 

Original comment by jonas.la...@gmail.com on 23 Mar 2011 at 10:13

[GoogleCodeExporter]

We never determined what the problem the original poster was having but I do 
know that having @Cacheable on a @Controller works just fine, I have 
applications that do this. I see you've emailed the list so I'll follow up 
further there.

Original comment by eric.dalquist on 23 Mar 2011 at 11:23

[GoogleCodeExporter]

I am having the same problem.  Whenever, I declare @Cachable on my bean 
interface, the autowired on that bean to others bean proxied instead of the 
concrete object. Did the problem resolved?

Original comment by Jacky.Won@gmail.com on 26 Jul 2011 at 2:45

[GoogleCodeExporter]

@Jacky.Won if you annotate an interface or object with @Cachable you will never 
see the concrete object, always a proxy of the interface. This is how the 
Spring AOP code works.

Original comment by eric.dalquist on 26 Jul 2011 at 3:46