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

Closed
spring-issuemaster opened this issue Oct 7, 2014 · 1 comment
Assignees
Milestone

Comments

@spring-issuemaster
Copy link
Collaborator

@spring-issuemaster spring-issuemaster 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:

@Service
@EnableScheduling
public class MyService {
    @Autowired
    private MyInjectedBean bean;

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

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

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

@spring-issuemaster spring-issuemaster 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.

Juergen

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.