"TargetListAggregatingBean" allows distributed collaboration to build up list-valued properties [SPR-2819]

[spring-projects-issues]

Antranig Basman opened SPR-2819 and commented

Several requests are outstanding in JIRA to improve Spring support for constructing list-valued properties, but I believe there is a deeper underlying issue which can be addressed. I have written up a possible solution as "TargetListAggregatingBean"

A brief summary of the issues -

• Whilst Spring has support for aggregating list-valued dependencies from the container, these must currently form a bounded set which is known to the recipient at definition time. In a more distributed architecture, it can become necessary for a recipient to express dependency on a collection whose members are drawn from a number of different contexts which cannot be known in advance. The standard Spring approach to this problem is ListableBeanFactory.getBeanNamesOfType, which is explained on the wiki page (link below) to suffer from two deficiencies, firstly in creating a framework dependency on the target, and secondly of being insufficiently fine-grained.

The TLAB solution allows any number of beans to express their contribution to the target list from around the context, by means of pure Spring definitions, and without exposing any additional dependencies to the recipient.

I have written up the issues and a solution on the RSF wiki on its own page:

http://www2.caret.cam.ac.uk/rsfwiki/Wiki.jsp?page=TargetListAggregatingBean

Implementation notes: i) All licenced under a Apache 1.1-style licence, no other encumbrance ii) implementation doesn't fundamentally have extraneous dependencies, but does currently use RSF's introspection scheme rather than javax.beans for performance reasons. iii) Currently packaged as a standard Spring BeanPostProcessor initialised by an ApplicationListener, an implementation integrated into the Spring core could be more slick :P

Other related JIRAs:

7488/SPR-230 - supply "adder" in addition to "setter". If adder-injection were supplied, this would ideally become TLABable.

6382 - A TLAB-delivered list would be a very good fit for being delivered to ChainOfResponsibilityFactoryBean

5784 - TLAB is in fact a more general implementation of "depends-on-after-created" (DOAC). The rationale for DOAC however would be unclear and most probably would reflect a poor design, unless the identified dependents were somehow delivered to the target. TLAB actually solves the underlying problem that DOAC is aimed at while insisting that the arrow of dependence remains aligned with the arrow of relative construction time.

---

Affects: 2.0 final

[spring-projects-issues]

Rossen Stoyanchev commented

This issue has been resolved through a selective bulk update, as part of a larger effort to better manage unresolved issues. To qualify for the update, the issue was either created before Spring 3.0 or affects a version older than Spring 3.0 and is not a bug.

There is a good chance the request was made obsolete, or at least partly outdated, by changes in later versions of Spring including deprecations. It is also possible it didn't get enough traction or we didn't have enough time to address it. One way or another, we didn't get to it.

If you believe the issue, or some aspects of it, are still relevant and worth pursuing at present you may re-open this issue or create a new one with a more up-to-date description.

We thank you for your contributions and encourage you to become familiar with the current process of managing Spring Framework JIRA issues that has been in use for over a year.