Bryant Harris has a new article published on DevX, called "The Why and How Behind Listener-Based Dependency Injection." The article discusses the ability to add listeners to a Spring-managed bean, via a custom Spring namespace.

The Spring Framework introduced many people to the idea of dependency injection, the notion that instead of looking up objects you need to collaborate with, you simply have them injected into your class via JavaBean-style getters and setters. This article introduces a new, complimentary form of dependency injection that is based not on properties but on the idea of channels and callback listeners. Much like classic dependency injection (which I consider property-based), this listener-based injection has the ability to reduce boilerplate code, promote looser coupling, and help make code more testable and reusable. In the same way that the JavaBean introspection used in dependency injection can infer properties by the presence of methods such as setPropertyName/getPropertyName, the listener introspection used in listener injection can infer communication channels on an object from methods such as addChannelName/removeChannelName, as the method signature defines the listener or callback interface. This article demonstrates how to use listener injection to clearly communicate relationships between POJOs using the Spring framework.

It's a neat idea. Not only is Mr. Harris using Spring's custom namespaces to extend Spring capabilities, but he's adding a feature that Spring 2.5 does not address via the @Autowired tag - autowiring injects one resource per annotation, and Mr. Harris offers a way to add multiple listeners to managed beans. It might be more convenient to have an annotation that matches by types (as the @Autowired annotation does) but this is a great first step.

Yes, listener injection would be very easy extend to compliment, work well with, etc other similar messaging style approaches such as annotation based techniques. For those curious, the listener based introspection API is released as open source under my oranjestad-commons project (http://oranjestad.sourceforge.net/commons) The Spring related bits (that wrap it as a spring namespace extension) come from the spring sub project (open source as well). (http://oranjestad.sourceforge.net/spring). The spring jar includes the commons jar in amongst its dependencies. Feedback is always welcome.

This really seems to be a combination of a Dependency Injection and the Adapter patterns. While the idea is a little cute and exciting, the introduction of the interface transformations (Adapter) within the scope of DI has me a little worried. DI is a powerful pattern with a limited scope whereas an Adapter is an exceptionally versatile pattern which can be used in a number of contexts. I think it might be a little more useful to keep the two separate. eg. in the article you mentioned call the tag orj:adapter instead of orj:listener. In that case the net effect is simply a combined application of a DI and an adapter pattern. Moreover you are now likely to be able to use the adapter in many other contexts than DI. My concern here is that Listener Based DI might seem to be something new whereas it seems to be an extension of DI using adapters. (note: listeners can always be registered using typical DI capabilities). Dhananjay

Correction:

My concern here is that Listener Based DI might seem to be something new whereas it seems to be an extension of DI using adapters

My concern here is that Listener Based DI might seem to be something new whereas it seems to be a combination of DI using adapters

I would say what is new is taking the DI concept, and applying it to another common pattern in programming other than properties. I certainly would agree that I heavily borrowed concepts from the (successful) approach used in JavaBeans introspection. As far as combining the adaptor capabilities with DI. The original work that lead to me building this involved the use of JMS. I needed a way to take 3rd party and/or pre-existing code and adapt their POJO style callbacks to publish onto our JMS queues. The only way to do this with out implementing each individual interface is to provide a generic listener that can implement any of the callback interfaces. So it seemed (and still seems) an appropriate abstraction to not *require* that all listeners implement the expected channels interface. But hey, if you like empty methods and boiler plate... no ones stopping you... :-p

Can you comment on how this compares with Spring AOP? Sarwar Bhuiyan

It's totally orthogonal to Spring AOP. It's based on an Introspection API that is heavily influenced by JavaBean introspection. So in the same way that JavaBean's introspection enables or simplifies Property based dependency injection. This introspection simplifies channel/listener based dependency injection.

I understand the implementations may be different but in terms of functionality, is it not providing the same thing? What is the benefit of Introspection over AOP?

I understand the implementations may be different but in terms of functionality, is it not providing the same thing?
What is the benefit of Introspection over AOP?

what are you talking about? this has nothing to do with AOP. this is traditional dependency injection with the added support of collaborator injection via addX/removeX methods rather than getX/setX methods. it's designed to support collaborators that are built around the Observer/Listener pattern. please read about the following topics before posting random questions: JavaBeans/POJOs Introspection OOP AOP DI/IOC