Configurable vs Component with Spring and AspectJ
-
23-08-2019 - |
Question
When using AspectJ, why use @Component over @Configurable.
I've got Spring and AspectJ setup for @Transactional support, aspects on self-invocation, and injection into JPA entities. This works great.
I'm using @Component for most classes that need injection, and thus either having them injected into their dependencies. Or, when I can't, injecting the ApplicationContext and then using getBean() as a last resort. And I'm reserving @Configurable for only JPA entities (Hibernate) that need injection. I've also started using @Configurable for jUnit tests, to make writing tests easy. This also works great.
But I'm curious. If AspectJ is now auto-injecting (beanifying) anything with the @Configurable annotation, regardless of how its constructed; getBean(), new(), @Autowired. Why wouldn't I just switch to using @Configurable for all my beans? Then I can do away with the application context and getBean() altogether, and just new() any classes I can't inject.
I realize that I made no mention of XML bean configuration. I don't shy away from that, but this project doesn't happen to require any. I just constructor or setter inject the dependencies when testing. very easy.
Solution
One reason why you should not always use @Configurable
is that it adds a lot of overhead: it often takes much longer for the app to start, and creating new instances becomes slower.
For @Component
you don't need it at all, because normally all the instances are managed by Spring.
OTHER TIPS
@Component is a Spring marker interface which can give Spring clues when it comes to auto-detection of beans.
@Configurable is a marker used by the AOP load-time-weaving stuff.
The two don't really have much to do with each other.
@Component
is for classes which will be instantiated by Spring itself, while @Configurable
is for classes which will be instantiated by your own code, or by another framework — entities by Hibernate or Servlets by the servlet container, for instance.