Tag Archives: method-injection

Spring Scoped Proxy Beans – An Alternative to Method Injection

Few months back, I wrote on JavaLobby about how you can use Method Injection in scenarios where bean lifecycles are different i.e. you want to inject a non-singleton bean inside a singleton bean. For those of you who are not aware of Method Injection, it allows you to inject methods instead of objects in your class. Method Injection is useful in scenarios where you need to inject a smaller scope bean in a larger scope bean. For example, you have to inject a prototype bean inside an singleton bean , on each method invocation of Singleton bean. Just defining your bean prototype, does not create new instance each time a singleton bean is called because container creates a singleton bean only once, and thus only sets a prototype bean once. So, it is completely wrong to think that if you make your bean prototype you will get  new instance each time prototype bean is called.

To make this problem more concrete, lets consider we have to inject a validator instance each time a RequestProcessor bean is called. I want validator bean to be prototype because Validator has a state like a collection of error messages which will be different for each request.

RequestProcessor class

@Component
public class RequestProcessor implements Processor {

    @Autowired(required = true)
    private Validator validator;

    public Response process(Request request) {
        List errorMessages = validator.validate(request);
        if (!errorMessages.isEmpty()) {
            return null;
        }
        return null;
    }

}

Validator class

@Component
@Scope(value = "prototype")
public class Validator {

    private List<String> errorMessages = new ArrayList<String>();

    public Validator() {
        System.out.println("New Instance");
    }

    public List<String> validate(Request request) {
        errorMessages.add("Validation Failed");
        return errorMessages;
    }

}

Because I am using Spring annotations, the only thing I need specify in xml is to activate annotation detection and classpath scanning for annotated components.

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:aop="http://www.springframework.org/schema/aop"
	xmlns:context="http://www.springframework.org/schema/context"
	xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
	http://www.springframework.org/schema/aop http://www.springframework.org/schema/aop/spring-aop-3.0.xsd
	http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-3.0.xsd">

	<context:annotation-config />

	<context:component-scan base-package="com.shekhar.spring.scoped.proxy"></context:component-scan>
</beans>

Now lets write a test to see how many instances of prototype bean gets created when we call the processor 10 times.

@ContextConfiguration
@RunWith(SpringJUnit4ClassRunner.class)
public class RequestProcessorTest {

    @Autowired
    private Processor processor;

    @Test
    public void testProcess() {
        for (int i = 0; i < 10; i++) {
            Response response = processor.process(new Request());
            assertNull(response);
        }
    }

}

If you run this test, you will see that only one instance of validator bean gets created as “New Instance” will get printed only once. This is because container creates RequestProcessor bean only once, and thus only sets Validator bean once and reuses that bean on each invocation of process method.

One possible solution for this problem is to use Method Injection which I have already talked about in my JavaLobby article. I didn’t liked method injection approach because it imposes restriction on your class i.e. you have to make your class abstract. In this blog, I am going to talk about the second approach for handling such a problem. The second approach is to use Spring AOP Scoped proxies which injects a new validator instance each time RequestProcessor bean is called. To make it work, the only change you have to do is to specify proxyMode in Validator class.

@Component
@Scope(proxyMode = ScopedProxyMode.TARGET_CLASS, value = "prototype")
public class Validator {

    private List<String> errorMessages = new ArrayList<String>();

    public Validator() {
        System.out.println("New Instance");
    }

    public List<String> validate(Request request) {
        errorMessages.add("Validation Failed");
        return errorMessages;
    }

}

There are four possible values for proxyMode attribute.I have used TARGET_CLASS which creates a class based proxy. This mode requires that you have CGLIB jar in your classpath.If you run your test again you will see that 10 instances of Validator class will be created. I found this solution more cleaner as I don’t have to make my class abstract and it makes unit testing of RequestProcessor class easier.

Pragmatic look at Method Injection

Intent

Method injection lets container inject methods instead of objects  and provides dynamic sub classing.

Also Known As

Method decoration (or AOP injection)

Motivation

Sometimes it happens that we need to have a factory method in our class which creates a new object each time we access the class. For example, we might have a RequestProcessor which has a method called process which takes a request as an input and returns a response as an output. Before the response is generated, request has to be validated and then passed to a service class which will process the request and returns the response.As can be seen in the code below we are creating a new ValidatorImpl instance each time process method is called. RequestProcessor requires a new instance each time because Validator might have some state which should be different for each request.

public class RequestProcessor implements Processor {

	private Service service;

	public Response process(Request request) {
		Validator validator = getNewValidatorInstance();
		List<String> errorMessages = validator.validate(request);
		if (!errorMessages.isEmpty()) {
			throw new RuntimeException("Validation Error");
		}
		Response response = service.makeServiceCall(request);
		return response;
	}

	protected ValidatorImpl getNewValidatorInstance() {
		return new ValidatorImpl();
	}

}

RequestProcessor bean is managed by dependency injection container like spring where as Validator is being instantiated within the RequestProcessor. This solution looks like ideal but it has few shortcomings :-

  1. RequestProcessor is tightly coupled to the Validator implementation details.
  2. If  Validator had any constructor dependencies, then RequestProcessor need to know them also. For example, if Validator has a dependency on some Helper class which is injected in Validator constructor then RequestProcessor needs to do know about helper also.

There is also another approach that you can take in which container will manage the Validator bean(prototype) and you can make bean aware of the container by implementing ApplicationContextAware interface.

public class RequestProcessor implements Processor,ApplicationContextAware {

	private Service service;
	private ApplicationContext applicationContext;

	public Response process(Request request) {
		Validator validator = getNewValidatorInstance();
		List<String> errorMessages = validator.validate(request);
		if (!errorMessages.isEmpty()) {
			throw new RuntimeException("Validation Error");
		}
		Response response = getService().makeServiceCall(request);
		return response;
	}

	protected Validator getNewValidatorInstance() {
		return (Validator)applicationContext.getBean("validator");
	}

	public void setApplicationContext(ApplicationContext applicationContext)
			throws BeansException {
		this.applicationContext = applicationContext;
	}

	public void setService(Service service) {
		this.service = service;
	}

	public Service getService() {
		return service;
	}

}

This approach also has its drawback as the application business logic is now coupled with Spring framework.
Method injection provides a better way to handle such cases.Method injection is an injection type in which methods are injected instead of objects. The key to Method injection is that the method can be overridden to return the another bean in the container.In Spring method injection uses CGLIB library to dynamically override a class.

Applicability

Use Method injection when

  • you want to avoid container dependency as we have seen in the second approach, in which you have to inject a non singleton bean inside a singleton bean.
  • you want to avoid subclassing. For example, suppose that RequestProcessor is processing two types of response and depending upon the the type of report , we use different validators. So, we can have subclass RequestProcessor and have Report1RequestProcessor which just provides the Validator required for Report1.
  • public class Report1RequestProcessor extends RequestProcessor {
    
    	@Override
    	protected Validator getNewValidatorInstance() {
    		return new ValidatorImpl();
    	}
    
    }
    
    public abstract class RequestProcessor implements Processor {
    
    	private Service service;
    
    	public Response process(Request request) {
    		Validator validator = getNewValidatorInstance();
    		List<String> errorMessages = validator.validate(request);
    		if (!errorMessages.isEmpty()) {
    			throw new RuntimeException("Validation Error");
    		}
    		Response response = getService().makeServiceCall(request);
    		return response;
    	}
    
    	protected abstract Validator getNewValidatorInstance();
    
    	public void setService(Service service) {
    		this.service = service;
    	}
    
    	public Service getService() {
    		return service;
    	}
    
    }
    

Implementation

Method injection provides a cleaner solution. Dependency Injection container like Spring will override getNewValidatorInstance() method and your business code will be independent of both the spring framework infrastructure code as well as Concrete implementation of Validator interface. So, you can code to interface.

public abstract class RequestProcessor implements Processor {

	private Service service;

	public Response process(Request request) {
		Validator validator = getNewValidatorInstance();
		List<String> errorMessages = validator.validate(request);
		if (!errorMessages.isEmpty()) {
			throw new RuntimeException("Validation Error");
		}
		Response response = getService().makeServiceCall(request);
		return response;
	}

	protected abstract Validator getNewValidatorInstance();

	public void setService(Service service) {
		this.service = service;
	}

	public Service getService() {
		return service;
	}

}

The method requires a following signature

<public|protected> [abstract] <return-type> methodName(no-arguments);

If the class does not provide implementation as in our class RequestProcessor, Spring dynamically generates a subclass which
implements the method otherwise it overrides the method. application-context.xml will look like this

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd">

	<bean id="service" class="com.shekhar.methodinjection.ExampleService" />

	<bean id="requestProcessor" class="com.shekhar.methodinjection.RequestProcessor">
		<property name="service" ref="service"></property>
		<lookup-method bean="validator" name="getNewValidatorInstance"/>
	</bean>

	<bean id="validator" class="com.shekhar.methodinjection.ValidatorImpl" scope="prototype">
	</bean>
</beans>

This is how method injection can be used in our applications.

Consequences

Method injection has following benefits:
1) Provides dynamic subclassing
2) Getting rid of container infrastructure code in scenarios where Singleton bean needs to have non singleton or prototype bean.

Method injection has following Liabilities :
1) Unit testing – Unit testing will become difficult as we have to test the abstract class. You can avoid this by making the method which provides you the instance as non-abstract but that method implementation will be redundant as container will always override it.
2) Adds magic in your code – Anyone not familiar with method injection will have hard time finding out how the code is working. So, it might make your code hard to understand.

Hope this helps you understand Method Injection. It is useful in specific cases as covered in this article.