Issue 1:
Endre Stølsvik opened SPR-2801 and commented

This request is similar to bug ##5727, "support "add"-style List injection", but suggests a more radical solution: Actual support for it in the spring beans xml-files: add-methods should be IoC-able in the same way as set-methods (and preferrably a mechanism to invoke any other method too, with any parameters).

As posted in:

http://forum.springframework.org/showthread.php?t=31058

quoting:

" Several types of "legacy beans" have "adder" methods for some properties instead of "setter" methods. This doesn't disqualify them from being handled as beans, I feel, but I can't figure out how I may invoke such a method in the same way as a property-setter? I have to be able to invoke such a method several times, obviously.. "

" I'd like to do this in spring's xml config, preferrably w/o a lot of hacks: I've come to understand that the org.springframework.beans.factory.config.MethodInvokingFactoryBean is the most cited approach to this problem, which I find on the edge of ridiculous.

I have this problem now with ActiveMQ, and I've had this problem with Jetty. Both have "addSomething": addConnector and addListener. "

" Jetty have its own style of "IoC" when it comes to configuration: in this file one may "code in XML" using <Call name="addListener"> and <New class=".."> (in addition to <Set name="...">). I know this isn't as clean as Spring, but at least one may get things done both with legacy and proper "IoC style" beans then.. "

Add elements to the bean element, something along the lines of:

<bean id="broker"

class="demo"

init-method="start"

destroy-method="stop">

<constructor-arg>

[ You know the deal ]

</constructor-arg>

<property name="setter">

[ You know the deal ]

</property>

<add-property name="adder">

[ Same semantics as ]

</add-property> [ multiple invocations to the same name must be allowed ]

<invoke name="someOtherMethod">

<argument>

[ Same semantics as ]

</argument> [ multiple invocations to the same name must be allowed ]

</invoke>

</bean>

There are hacks to overcome this, read the referred thread (using org.springframework.beans.factory.config.MethodInvokingFactoryBean w/o really using it!), but this is obviously a thing that comes up from time to time in the forums, and it would be great if such style of configuration was supported natively. (btw: At least jetty could possibly use spring instead of its own config parsing then!).

Affects: 2.0 final

Issue Links:

#4961 Please improve BeanFactory support for containers & collections ("duplicates")

3 votes, 2 watchers

Issue 2:
Ben Hutchison opened SPR-230* and commented

Objects that contain other objects (common examples include Swing Containers and the Collections classes) frequently cannot have their initial state specified through setting javabeans properties alone.

This is a request for the spring core to include extensions to the syntax of the applicationContext.xml to allow such objects to be setup completely from XML. Some reasonably conveinient syntax is needed that allows methods like "add()" to be invoked on the bean at construction time. Ideally, I think the syntax should allow any arbritrary methods to be called on a bean during preparation.

There is a clear precendent to be found in the design of the java.beans.XMLEncoder/Decoder classes, designed to support long term bean perisstence. Consider the extract below generated by XML-serializing a List:

<?xml version="1.0" encoding="UTF-8" ?>

<java version="1.4.2_03" class="java.beans.XMLDecoder">

<object class="java.util.ArrayList">

<void method="add">

<string>item</string>

</void>

</object>

</java>

Evidently, it was recognized as an important feature as its present from the first release of the peristence mechanism.

Consider what is not readily doable from XML without this feature:

Cannot create any Swing component heirarchies.

Cannot initialize custom collections (ie anything not a vanilla set/map/list impl), unless it provides a copy-constructor.

Cannot init arbritrary state on objects which do not observe the get/setXXX convention (and legacy code is littered with them).

Affects: 1.0.2

Attachments:

SPR-230.patch (137.30 kB)

Issue Links:

#7195 Allow setting of properties without a javabean setter ("is duplicated by")

#7222 Support JavaBean Eventing methods in Spring ("is duplicated by")

#7488 "adder" injection in addition to "setter" (invoke addXX() instead of setXX()) ("is duplicated by")

#5727 support "add"-style List injection ("is duplicated by")

32 votes, 28 watchers