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

ProxyAsyncConfiguration is eagerly loaded due to AsyncAnnotationBeanPostProcessor [SPR-12761] #17358

Closed
spring-issuemaster opened this issue Feb 27, 2015 · 3 comments

Comments

Projects
None yet
2 participants
@spring-issuemaster
Copy link
Collaborator

commented Feb 27, 2015

Artem Bilan opened SPR-12761 and commented

The test-case to reproduce:

@ContextConfiguration
@RunWith(SpringJUnit4ClassRunner.class)
public class EnableAsyncTests {

	@Test
	public void testIt() {}

	@Configuration
	@EnableAsync
	public static class ContextConfiguration {

	}

}

And we see in logs:

2015-02-27 12:47:46,007 INFO PostProcessorRegistrationDelegate$BeanPostProcessorChecker [main] : Bean 'org.springframework.scheduling.annotation.ProxyAsyncConfiguration' of type [class org.springframework.scheduling.annotation.ProxyAsyncConfiguration$$EnhancerBySpringCGLIB$$5806bc78] is not eligible for getting processed by all BeanPostProcessors (for example: not eligible for auto-proxying)

As far as I can tell making ProxyAsyncConfiguration.asyncAdvisor() bean-method as static should fix the issue, because AsyncAnnotationBeanPostProcessor is BeanPostProcessor.


Affects: 4.1.5

Referenced from: commits 772a26a, 31df715

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Feb 27, 2015

Juergen Hoeller commented

Unfortunately, just making it static won't work since the arrangement relies on ImportAware processing which is only available for non-static configuration class instances.

I suppose this eager loading of the configuration class doesn't cause any actual issues to begin with. So we could also re-consider refining BeanPostProcessorChecker towards ignoring synthetic beans, and making sure that @Enable-triggered beans are indeed marked as synthetic. This is not the first time we're considering this, after all.

Juergen

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Mar 5, 2015

Stéphane Nicoll commented

Revisited the condition to exclude infrastructure beans as those won't be a target for such post-processing.

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Mar 5, 2015

Artem Bilan commented

Great! Thank you, Stéphane Nicoll!
With that we can mark some our internal beans with ROLE_INFRASTRUCTURE to avoid that noise as well.

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