Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Private @Scheduled methods end up on 'empty' proxy instance in case of CGLIB auto-proxying [SPR-12308] #16913

spring-projects-issues opened this issue Oct 7, 2014 · 1 comment
in: core status: backported type: bug


Copy link

@spring-projects-issues spring-projects-issues commented Oct 7, 2014

Yonatan Graber opened SPR-12308 and commented

When having a bean with a @Scheduled private method, the scheduled invocation when a pointcut exists for that method will succeed, but nothing will get injected into @Autowired fields. Setting other visibility for the method would solve it.

For example:

public class MyService {
    private MyInjectedBean bean;

    @Scheduled(fixedDelay = 5000)
    private void ping(){
        System.out.println("Pinging bean "+bean);

The above code will work if no AOP is defined. If an @Around aspect is defined, ping will throw a NullPointException. Changing ping to be package protected will cause it to work again.

If there's a technical implementation problem with scheduling a private method under those conditions, I expect it to fail the deployment, rather than providing a sterile, non-injected bean.

Affects: 3.2.11, 4.0.7

Referenced from: commits 473d973, 01724d3, 47ed4d6

Backported to: 4.0.8, 3.2.12

Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Oct 7, 2014

Juergen Hoeller commented

This is indeed a technical limitation: Private methods on CGLIB proxies cannot be overridden in the generated runtime subclass, so they'll end up in the CGLIB proxy instance itself, not delegated to the actual target bean. And that proxy instance appears 'empty' since it hasn't got any state itself... Calls should never end up in such an instance to begin with.

We are going to reject such scenarios with an IllegalStateException as of 4.1.2, and at least going to log a warning in 4.0.8 and 3.2.12.


Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
in: core status: backported type: bug
None yet

No branches or pull requests

2 participants