In this blog entry I introduce small library that extends base functionality of Spring framework by allowing specifying references between in beans using "opposite" direction of them comparing to standard Spring approach.

What I’ve tried to solve

Several days ago I’ve blogged about necessity and possibilities of specifying dependencies in Spring context using "opposite" direction of references.

In just two words, if we have, say, two beans defined within context, and first bean refers to other bean, that reference should be described within bean context configuration XML directly as part of referring bean definition. This is casual and "natural" Spring way of defining dependencies between beans.

However, for some types of applications that approach does not work. The major drawback of it is as follows: during definition of referring bean it’s assumed that the name of bean to which it refers is known.

Unfortunately, for applications that are built using plugin architecture, that assumption becomes serious limitation, since it does not allow to create really extensible application without necessity of Spring context modification – of course, that does not corresponds to overall idea of plugins at all. And that’s even more sad if we’ll consider functionality that is already included into Spring – like creation of application context from several files that could be resolved dynamically (say, via direct list of their locations or via wildcards withing classpath).

Therefore, to obtain truly extensible applications, we need to have ability to "extend" existing content of Spring context.

From that point of view, the application may include, for example, one or more Spring configuration files with beans that represents "extension points" and, several dynamically loaded modules of plugins which may include beans that may be plugged into that extension points.

The following picture illustrates this concept:

What should be considered as extension point there? Well, the answer is pretty simple there – just properties of some beans. We have named bean, we have named property – so we could address the point where we could inject our reference pretty precise.

Of course, in extending context we need to know names of beans and properties to which we may inject beans from extending contexts. However, this issues is completely different to original approach of Spring – in such case, beans in "core" context represents a kind of dynamic API (pretty funny, but I suppose that such and context definition may be considered as API without API), and at the moment of defining beans in "core" context we are completely not aware how ones will be customized later (or even probably by third-party plugin developer).

Ok, now that we have extension points, the only thing we need to make the entire concept of such injection live is just an ability to specify that beans should be wired outside of referencing bean definition.

In other words, here we need to have some mechanism which will said Spring that beans should be wired not in "core" context, but directly in "extending" one.

The following picture illustrates difference between "normal" and "opposite" directions of references:

Now we are almost ready to move further. The only thing that we need to consider at the moment is types of references. Spring provides several standard ways to specify references between beans:

• using ordinary reference;
• using list of beans;
• using map of beans;
• using set of beans.

And, of course, there is ability to specify value of particular property. If we’ll look on these ways of defining relations between beans it will be clear that it’s quite possible to use opposite direction of injection to support them.

Inject4Spring overview

Well, that was background for tasks which are solved by Inject4Spring library. It’s a small (about 35k in jar) library which I wrote about year ago to have support of such "opposite" directions of specifying references between beans. At the moment, we’ve used it in several projects developed in SoftAMIS. Inject4Spring is released under Apache License, so it could be used both in open source and commercial applications.

In general, while it could be used for Spring 1.x, primarily it’s targeted to Spring 2.x, since it heavy relies on custom namespaces functionality introduced in Spring 2.0. Actually, from the usage point of view, all functionality of that library is exposed via set of custom XML tags that belongs to "inject" namespace.

Here is brief overview of possible types of dependencies in Spring and custom tags included into Inject4Spring that corresponds them:

License and download

Inject4Spring is released under Apache License, so it could be used both in open source and commercial applications. At the moment, you may to download it directly from our site, but probably later I’ll move it as project on SourceForge or something like that.

At the moment it’s quite stable and we’ve used it during last year for several projects. However, if you’ll have some comments, issues, requests for improvements – please do not hesitate contacting me

The Inject4Spring library was developed in SoftAMIS, a Ukraine based software development company specialized on Java and Web development outsourcing services. To find more about SoftAMIS, our services, skills and experience, please visit our site –

http://www.soft-amis.com

The home page of Inject4Spring is currently located here