Inject4Spring - opposite direction of references injection

[Andrew Sazonov]

Inject4Spring is a small Open Source library that extends base functionality of Spring framework by allowing wiring beans in Spring context using "opposite" direction comparing to standard Spring approach.

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.

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

Inject4Spring provides ability to wire beans using "opposite" direction of references - something like that:

<bean name="InjectionBean" class="....">
<inject:to-ref target="InjectTarget" name="beanRefEmpty"/>
</bean>

or, for list (actually, reference, list, set and map based dependencies are supported by Inject4Spring)

<bean name="InjectionBean" class="...">
<inject:to-list target="InjectTarget" name="beansList"/>
</bean>

In other words, instead of having reference on bean that "REFERS" to another bean, with such notation we are able to specify that reference on bean declaration which is actually "REFERENDED" by another bean.


Well, that's just very short overview. Please refer to my blog for more details about that approach and for downloading Inject4Spring...

Oops, it seems that forum does not allow me to post URL... That's really sad...
Ok, sorry for that - you can more about Inject4Spring here

h t t p : //andrew.sazonov.name (funny, right? )


I hope you'll find that small library useful.

Regards,
Andrew Sazonov

[al0]

I guess that your library is a weird as your inability to post URL (sorry, just joke, no offence intended) http://andrew.sazonov.name.

Why, for god's sake bean has to know its consumers?

Kind regards,
Oleksandr

[Andrew Sazonov]

Hi Oleksandr,

Yes, inability to post URL was sad...

Why, for god's sake bean has to know its consumers?

Ok, that's pretty simple - let's imagine we have some application (in general, non-web one) that is built using plugins scheme. And ones is based on Spring.

Obviously, we have some basic logic encapsulated in beans stored in "core" Spring context.

Later, we'd like to extend that core functionality by one provided by plugins (and please mind that it could be thirdparty plugins that are developed after application release).

And here we have weird issue - it's not clear how to extend bean definition that is already placed in core spring contex...

Just as example - it's slightly artificial, yet should highlight the idea - what if we have some UI place that shows dynamic list of actions. Actions are ordinary beans and are defined in Spring context.

There is appropriate provider for that actions which contains list of actions that should be shown. Without modification of original context, we simply unable to add another bean to that list to show additional action delivered by plugin.

And that's why such an "opposite" direction of injection (from plugin to core context) is necessary for such king of applications...

Regards,
Andrew

[al0]

Context may have several beans with same id, last wins.
so I just add file with provider (or list) redifinition(s) at the end of context files list. That's all. No injection in the opposite direction.

Hi Oleksandr,

Yes, inability to post URL was sad...



Ok, that's pretty simple - let's imagine we have some application (in general, non-web one) that is built using plugins scheme. And ones is based on Spring.

Obviously, we have some basic logic encapsulated in beans stored in "core" Spring context.

Later, we'd like to extend that core functionality by one provided by plugins (and please mind that it could be thirdparty plugins that are developed after application release).

And here we have weird issue - it's not clear how to extend bean definition that is already placed in core spring contex...

Just as example - it's slightly artificial, yet should highlight the idea - what if we have some UI place that shows dynamic list of actions. Actions are ordinary beans and are defined in Spring context.

There is appropriate provider for that actions which contains list of actions that should be shown. Without modification of original context, we simply unable to add another bean to that list to show additional action delivered by plugin.

And that's why such an "opposite" direction of injection (from plugin to core context) is necessary for such king of applications...

Regards,
Andrew

[Andrew Sazonov]

Context may have several beans with same id, last wins.
so I just add file with provider (or list) redifinition(s) at the end of context files list. That's all. No injection in the opposite direction.

Well, in general, yes - if bean overriding is allowed for context. For simple cases such approach may work.

However, it does not solve the problem if 2 independent plugins provide functionality that should extend core one (consider example with list - one plugin adds 2 actions and another plugin adds ANOTHER two actions) - it's simply not clear which declaration should be the last one (and, of course, using approach with complete re-declaration, these plugins are tightly coupled).

Regards,
Andrew

[al0]

In such case collection merging (another Spring feature) may help.

Well, in general, yes - if bean overriding is allowed for context. For simple cases such approach may work.

However, it does not solve the problem if 2 independent plugins provide functionality that should extend core one (consider example with list - one plugin adds 2 actions and another plugin adds ANOTHER two actions) - it's simply not clear which declaration should be the last one (and, of course, using approach with complete re-declaration, these plugins are tightly coupled).

Regards,
Andrew