Bernie's Blog A confusing concoction of Java, mobile devices, technology and photography

Google Guice @Provider Gotcha

Note: Best read after some background reading on Google Guice and dependency injection.

I spent many hours pouring through my codes to resolve this so I'm posting this as a guide to others.

Scenario:

Google Guice allows Providers to be defined, either using the @Provider annotation or by implementing the Provider interface. To those new to Guice, here's a simple explanation on providers:

When you need code to create an object, use an @Provides method

In other words, when you need to inject an object that needs some sort of setup code, or when you need to customize what is injected, you resort to using a Provider. Here's a code snippet that injects a chain of handlers (read: Chain of Responsibility pattern):

@Provides
	private ErResponseHandler provideResponseHandlers() {
		// builds the handlers manually - chain of responsibility pattern
		ErResponseHandler handler = new InactivateAccountResponseHandler(
				new UsageAuthRateChargeResponseHandler());
		return handler;
	}

And this is BaseResponseHandler - a base class which implements ErResponseHandler.

public abstract class BaseResponseHandler implements ErResponseHandler {

        @Inject
	protected XmlBinder xmlbinder;

	public BaseResponseHandler() {
	}
	private ErResponseHandler next;
	public BaseResponseHandler(final ErResponseHandler nextHandler) {
		this.next = nextHandler;
	}
	public final boolean start(final ErResponse response) {
		boolean handled = this.handleResponse(response);
		if (next != null && !handled) {
			next.start(response);
		}
		return handled;
	}
	public abstract boolean handleResponse(ErResponse resp);
}

Everything seems to be in order, right? Straightforward dependency injection of xmlbinder, except of course, this does not work. Xmlbinder is always null. The problem is that once you take over the job of providing your own objects to be injected, injection doesn't work automagically any more. You'll have to wire up your objects manually too.

Solution:

The provider method has to be changed to:

@Provides
        //XmlBinder has been bound using the application Module
	private ErResponseHandler provideResponseHandlers(XmlBinder xmlbinder) {
		// builds the handlers manually - chain of responsibility pattern
		ErResponseHandler handler = new InactivateAccountResponseHandler(
				new UsageAuthRateChargeResponseHandler());
		handler.setXmlBinder(xmlbinder);
		return handler;
	}

Of course, the BaseResponseHandler class now has to set the xmlbinder accordingly:

public abstract class BaseResponseHandler implements ErResponseHandler {

	protected XmlBinder xmlbinder;	

	public BaseResponseHandler() {
	}
	private ErResponseHandler next;
	public BaseResponseHandler(final ErResponseHandler nextHandler) {
		this.next = nextHandler;
	}
        public void setXmlBinder(final XmlBinder binder) {
		this.xmlbinder = binder;
		if (next != null) {
			next.setXmlBinder(binder);
		}
	}
	public final boolean start(final ErResponse response) {
		boolean handled = this.handleResponse(response);
		if (next != null && !handled) {
			next.start(response);
		}
		return handled;
	}
	public abstract boolean handleResponse(ErResponse resp);
}

Unfortunately, Guice's documentation mentions this only in passing:

Dependencies can be passed in as parameters to the method. The injector will exercise the bindings for each of these before invoking the method

It should really be phrased as

Dependencies must be passed in as parameters to the method. Only then will the injector exercise the bindings for each of these before invoking the method.