Over a million developers have joined DZone.

Spring Dependencies - Opposite Direction, Please?

DZone's Guide to

Spring Dependencies - Opposite Direction, Please?

· Java Zone ·
Free Resource

Get the Edge with a Professional Java IDE. 30-day free trial.

Here we'll see how to manage dependencies between beans in Spring framework context using "opposite direction" of such dependencies.

Spring is great in providing inversion of control container, instantiating beans, wiring them as well as managing their lifecycle. But can it be improved there?

Yes, Spring Framework is great. No doubts. I remember that excitement when I played with it first time (that's was several years ago). That's was great to see that after providing proper configuration the magic happened - all beans were instantiated and more importantly, they were wired together by container...

At that moment inversion of control was pretty new concept and things that were handled by Spring impressed us too much. Right at that time we've completed pretty large product that required sophisticated setup of components and dependencies between them and so we were totally disappointed that Spring appeared late..

Ok, Spring is great. But definitely one can be improved in some areas. Let's leave warious holy wars related to Spring alone and take a look to it's basic functionality - the IoC container. After all, that's one of the basic concept of Spring - so probably we'll be able to polish it a little there?

Let's imagine that we have two beans in our Spring context - BeanA and BeanB. And BeanA has property to which BeanB should be wired. If we'll omit autowiring issues there, such a dependency will be described in Spring context XML as follows:

<bean class="..." id="BeanA">
<property name="propertyThatRefersToB" ref="BeanB"/>

<bean id="BeanB" class="..."/>

or, it could be even shorter if p: namespace from Spring 2.x is used:

<bean class="..." id="BeanA" 

In general, this way to instruct the Spring how to inject BeanB to BeanA is pretty fine and is more than enough in most situation.

Unfortunately, not in all.

The overall concept of Spring framework assumes that context is assembled when all beans are known (and that's pretty natural). However, that approach does not work well if application should be built using not solid, but rather plugin based architecture.

Recently, in one of projects we develop here in SoftAMIS we've got the same issue - the overall system should support dynamically loaded plugins (actually, the entire application could be considered as set of plugins) and, what is more important, generally speaking, that set of plugins is unknown so new plugins may be added later as well as existing ones may be disabled.

That's was the case were Spring container simply may fail...

Fortunately, in our application, plugins are assembled only during application startup, so we got different challenge - how to compose final Spring context from several configuration files. Since Spring initially supported dividing entire application context by several configuration files, that's was not to hard.

However, here we still had little trouble - in Spring, to make reference to bean, you need to know name of that bean. That's was obviously not acceptable for plugins - and what we needed there is ability to specify that reference not on parent bean (BeanA), but on bean that is referred - (BeanB).

Thus, instead of having top-to-bottom direction of references, we needed opposite one, that assumes that directly on the bean we may specify where one should be injected. The following picture illustrates such a difference between these approaches:

Difference between dependency directions

We've tried to find ready solution for that, but didn't find any that can satisfy our needs (please thing that actually there more complex types of references between beans exists - via list, map and set, for example).

So, necessity is mother of progress - and we've created small library that allows to have such opposite injections in Spring.

Thanks to support of custom namespaces in Spring 2.x, resulting markup was pretty simple. Like that:

<bean class="..." id="BeanA"/>

<bean class="..." id="BeanB">
<inject:to-ref target="BeanA" name="propertyThatRefersToB"/>

Pretty simple, right? Please note tag from custom namespace (supported by Spring 2.x):

<inject:to-ref target="BeanA" name="propertyThatRefersToB"/>

Using it now we've just inverted direction in which we declare references between beans in Spring context - BeanA just could be considered as extension point which underlying BeanB may be plugged into. And think about having such ability to dynamically plug bean into list or map (yes, we have them already too) ....

Well, that's was description of generic idea. One of these days I'll post more detailed entry about that technology as well as provide complete source code for it - so stay tuned!


I've added another entry to my blog that describes this issue more. And, from there the Inject4Spring library is available - it provides support for concepts I've described there.

Please use the following link to get it:

Introducing Inject4Spring

Get the Java IDE that understands code & makes developing enjoyable. Level up your code with IntelliJ IDEA. Download the free trial.


Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}