In an earlier post, I wrote about using the Spring BeanPostProcessor to inject cross-cutting concerns. That can easily be extended to inject a proxy more transparently across all beans in the application context. The key is to use the BeanFactoryPostProcessor in conjunction with the post-processor. Define a custom class that implements the factory post processor like the following:
package learn; public class ExampleBeanPostProcessorFactory implements BeanPostProcessorFactory { @Override void postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory) { beanFactory.addBeanPostProcessor(new ExampleBeanPostProcessor()); } }
Define this bean alongside the the rest of your declarations. For instance:
<bean class="learn.ExampleBeanPostProcessorFactory" />
The post processor can be injected with required dependencies per your needs – this could be a bean that wraps all annotated objects with instrumentation via the Java Dynamic proxy. The key benefit is that the beans in your context can all be transparently examined and proxied – how to decide which beans need to be proxied can be determined by annotations or beans implementing certain interfaces or custom decision logic using a class.
Tagged: annotations, bean post processor, cross cutting concerns, dynamic proxy, java, software reuse, spring framework
