Al usar AspectJ, por qué usar @Component sobre @Configurable.Configurable vs Componente con Spring y AspectJ
Tengo la configuración de Spring y AspectJ para soporte de @Transactional, aspectos sobre auto invocación e inyección en entidades JPA. Esto funciona genial
Estoy usando @Component para la mayoría de las clases que necesitan inyección y, por lo tanto, las he inyectado en sus dependencias. O, cuando no puedo, inyectar ApplicationContext y luego usar getBean() como último recurso. Y estoy reservando @Configurable solo para entidades JPA (Hibernate) que necesitan inyección. También comencé a utilizar @Configurable para las pruebas jUnit, para facilitar las pruebas de escritura. Esto también funciona genial.
Pero tengo curiosidad. Si AspectJ ahora está autoinyectando (beanifying) cualquier cosa con la anotación @Configurable, independientemente de cómo se construya; getBean(), new(), @Autowired. ¿Por qué no cambiaría simplemente a usar @Configurable para todos mis beans? Entonces puedo eliminar el contexto de la aplicación y getBean() en conjunto, y simplemente new() cualquier clase que no pueda inyectar.
Me doy cuenta de que no mencioné la configuración del bean XML. No evito eso, pero este proyecto no requiere ninguno. Yo solo constructor o setter inyectan las dependencias cuando prueban. muy fácil.