Inject4Spring - opposite direction of references injection

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? :mad:)


I hope you'll find that small library useful.

Regards,
Andrew Sazonov

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

Hi Oleksandr,

Yes, inability to post URL was sad... :)

Quote:

---

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

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.

Quote:

---

Originally Posted by Andrew Sazonov

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

---

Quote:

---

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

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

Quote:

---

Originally Posted by Andrew Sazonov

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

---

Quote:

---

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

---

Hm... not sure that I understand how that could be done - as far as I know, merging of collections works for parent-child bean definitions, not for beans overriding... Or probably I miss something? Could you please expand that?

And yet another option - using factory bean to build list definition - this factory bean may collect from context all beans that implement e.g. Plugin interface and
build list of them. Yes. implementation of such factory bean requires some lines of Java code, but only few.

So for almost every situation problem may be solved by means of already existing Spring functionality.

Quote:

---

Originally Posted by al0

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

---

Sure, but if you aticipate that some functionality would be expanded by plugins,
you may always define orginal list as abstract bean, but inject its concrete child. But yes, it seems that in this case at least one plugin need to know about presence of other. Not very good indeed.

Quote:

---

Originally Posted by Andrew Sazonov

Hm... not sure that I understand how that could be done - as far as I know, merging of collections works for parent-child bean definitions, not for beans overriding... Or probably I miss something? Could you please expand that?

---

Quote:

---

Originally Posted by al0

And yet another option - using factory bean to build list definition - this factory bean may collect from context all beans that implement e.g. Plugin interface and
build list of them. Yes. implementation of such factory bean requires some lines of Java code, but only few.

---

What if we need to areas where we need to show actions? It seems that there should be logic in factory that which accept only specific ones :) And for different place you'll still need custom logic... and so on. I suppose it's simpler to have some reusable mechanism for that.

Quote:

---

Originally Posted by al0

So for almost every situation problem may be solved by means of already existing Spring functionality.

---

Yes, in general, that's possible... but what for? I don't think it's practical to consider Spring as closed ecosystem - all it internal architecture was created with assumption of further extension (I mean protected methods, factory methods, internal factories and policies) and it's pretty easy to customize or expand it as necessary (of course, if that's practical).

I simply suppose that for tasks we've solved, that approach supported by Inject4Spring was pretty convenient - sure thing, it's not a silver bullet and it will be hardly needed for all applications.