Aug 29, 2015
Spring @Configuration vs @Component
That said, there is a ‘lite’ mode of @Bean processing where we don’t apply any CGLIB processing: simply declare your @Bean methods on classes not annotated with @Configuration (but typically with another Spring stereotype instead, e.g. @Component). As long as you don’t do programmatic calls between your @Bean methods, this is going to work just as fine.
Simply put, each application context configuration shown below will act in a totally different way:
The first piece of code works fine, and as expected,
SimpleBeanConsumer will get a link to singleton
But unfortunately, it doesn’t work in a signed enviroment.
The second configuration is totally incorrect because spring will create a singleton bean of
will obtain another instance of
SimpleBean which is out of the spring context control.
The reason for this behaviour can be explained as follows:
If you use
@Configuration, all methods marked as
@Bean will be wrapped
into a CGLIB wrapper which works as if it’s the first call of this method, then the original method’s body will be executed and the resulting object will be
registered in the spring context. All further calls just return the bean retrieved from the context.
In the second code block above,
new SimpleBeanConsumer(simpleBean()) just calls a pure java method. To correct the second code block, we can do something like this:
All code examples for this post can be found at my GitHub profile.
- 01/29 Scala testing with a human face
- 01/02 Scala with a human face
- 11/27 Dynamic bean definition for automatic FilterRegistrationBeanFactory unregistration
- 08/16 CGLIB: signer information does not match signer information of other classes
- 07/26 The magic of @Transactional and its performance
- 07/22 WebApplicationContext in the stand-alone application