summary of Spring method injection

Method Injection was introduced in Spring 1.1, which comes in two loosely related forms, Lookup Method Injection and Method Replacement.

Lookup Method Injection

It's added to overcome the problems encountered when a bean depends on another bean with a different lifecycle - specifically, when a singleton depends on a non-singleton.

Here's an example, we create one non-singleton bean and two singleton beans that both implement the same interface. One of the singletons obtains an instance of the non-singleton bean using "traditional" setter injection; the other uses Method Injection.

java: non-singleton bean 

public class MyHelper {

    public void doSomethingHelpful() {
        // do something!
    }
}

java: this interface will be implemented by two singleton beans

public interface DemoBean {

    public MyHelper getMyHelper();
    public void someOperation();
}

java: traditional singleton bean

public class StandardLookupDemoBean implements DemoBean {

    private MyHelper helper;

    public void setMyHelper(MyHelper helper) {
        this.helper = helper;
    }

    public MyHelper getMyHelper() {
        return this.helper;
    }

    public void someOperation() {
        helper.doSomethingHelpful();
    }
}

java: method injection bean

public abstract class AbstractLookupDemoBean implements DemoBean {

    public abstract MyHelper getMyHelper();

    public void someOperation() {
        getMyHelper().doSomethingHelpful();
    }
}

xml: configuration file

<!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN"
"http://www.springframework.org/dtd/spring-beans.dtd">
<beans>
    <bean id="helper" class="MyHelper"
          singleton="false"/>
    <bean id="abstractLookupBean"
          class="AbstractLookupDemoBean">
        <lookup-method name="getMyHelper" bean="helper"/>
    </bean>
    <bean id="standardLookupBean"
          class="StandardLookupDemoBean">
        <property name="myHelper">
            <ref local="helper"/>
        </property>
    </bean>
</beans>

Use Method Lookup Injection when you're working with beans of different lifecycles rather than implementing BeanFactoryAware and performing the lookup manually. Using Method Lookup Injection, you can keep your beans decoupled from Spring without any noticeable performance loss.

Although you don't have to make your lookup method abstract, doing so prevents you from forgetting to configure the lookup method and then using a blank implementation by accident.

Method Replacement

Using method replacement, you can replace the implementation of any method on any beans arbitrarily without having to change the source of the bean you are modifying.

Internally you achieve this by creating a subclass of the bean class dynamically. You use CGLIB and redirect calls to the method you want to replace to another bean that implements the MethodReplace interface.

java: any one of the two formatMessage methods can be replaced

public class ReplacementTarget {

    public String formatMessage(String msg) {
        return "<h1>" + msg + "</h1>";
    }

    public String formatMessage(Object msg) {
        return "<h1>" + msg + "</h1>";
    }
}

java: method replacer class, must implement MethodReplacer interface

public class FormatMessageReplacer implements MethodReplacer {

    public Object reimplement(Object target, Method method, Object[] args)
            throws Throwable {

        if (isFormatMessageMethod(method)) {

            String msg = (String) args[0];
            return "<h2>" + msg + "</h2>";
        } else {
            throw new IllegalArgumentException("Unable to reimplement method "
                    + method.getName());
        }
    }

    private boolean isFormatMessageMethod(Method method) {

        // check correct number of params
        if (method.getParameterTypes().length != 1) {
            return false;
        }
        // check method name
        if (!("formatMessage".equals(method.getName()))) {
            return false;
        }
        // check return type
        if (method.getReturnType() != String.class) {
            return false;
        }
        // check parameter type is correct
        if (method.getParameterTypes()[0] != String.class) {
            return false;
        }
        return true;
    }
}

xml: mind the replaced-method portion

<!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN"
"http://www.springframework.org/dtd/spring-beans.dtd">
<beans>
    <bean id="methodReplacer"
          class="FormatMessageReplacer"/>
    <bean id="replacementTarget"
          class="ReplacementTarget">
        <replaced-method name="formatMessage" replacer="methodReplacer">
            <arg-type>String</arg-type>
        </replaced-method>
    </bean>
    <bean id="standardTarget"
          class="ReplacementTarget"/>
</beans>

java: testing code piece

public class MethodReplacementExample {

    public static void main(String[] args) {
        BeanFactory factory = new XmlBeanFactory(new FileSystemResource(
                "./replacement.xml"));

        ReplacementTarget replacementTarget =
                          (ReplacementTarget) factory.getBean("replacementTarget");
        ReplacementTarget standardTarget =
                             (ReplacementTarget) factory.getBean("standardTarget");

        displayInfo(replacementTarget);
        displayInfo(standardTarget);
    }

    private static void displayInfo(ReplacementTarget target) {
        System.out.println(target.formatMessage("Hello World!"));

        StopWatch stopWatch = new StopWatch();
        stopWatch.start("perfTest");

        for (int x = 0; x < 1000000; x++) {
            String out = target.formatMessage("foo");
        }

        stopWatch.stop();

        System.out.println("1000000 invocations took: "
                + stopWatch.getTotalTimeMillis() + " ms");
    }
}

result:

<h2>Hello World!</h2>
1000000 invocations took: 3609 ms
<h1>Hello World!</h1>
1000000 invocations took: 844 ms

We still prefer to use standard Java mechanisms for overriding methods rather than depending on runtime bytecode enhancement. If you're going to use it, the recommendation is to use one MethodReplacer per method or group of overloaded methods. Avoid the temptation to use a single MethodReplacer for lots of unrelated methods; this results in lots of unnecessary String comparisons.