Enterprise Integration Zone is brought to you in partnership with:

Vijay Narayanan is a systematic reuse evangelist building reusable data services and business process automation components. He has worked on several software projects ranging from single user systems to large, distributed, multi-user platforms with several services. He is a technologist focusing on software reuse, agile development, and Service Oriented Architecture (SOA). Vijay is a DZone MVB and is not an employee of DZone and has posted 41 posts at DZone. You can read more from them at their website. View Full User Profile

Using Spring & Java Annotations to Inject Reusable Capabilities – Part II

08.28.2012
| 4328 views |
  • submit to reddit

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.

Published at DZone with permission of Vijay Narayanan, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)