Over a million developers have joined DZone.

The Grails Depedency Injection Inheritance Pitfall

· Java Zone

Learn more about how the Java language, tools and frameworks have been the foundation of countless enterprise systems, brought to you in partnership with Salesforce.

This blog post is about a small pitfall you should be aware of when combining dependency injection in Grails with inheritance.

I think the problem is best explained with a piece of example code. So let's look at the following two definitions of Grails controllers.

class FooController {
	TestService testService

	def foo() {
		// do something with testService
	}
}
class BarController extends FooController {
	TestService testService

	def bar() {
		// do something with testService
	}
}

Both controllers look nearly identical. The only difference is that BarController extends FooController. Now assume we have an instance of BarController and we want to call the methods bar() and foo() on it. Guess what happens?

The call of bar() works fine while the call of foo() throws a NullPointerException becausetestService is null.

testService is a standard Groovy property. This means that the testService fields will become private and getter / setter methods are generated for both controllers. The getter / setter of BarControlleroverride the getter / setter of FooController. So whenever the dependency is injected usingsetTestService() only BarController retrieves the TestService instance. This is nothing special about Grails controllers, it works the same for services and other Groovy classes.

The solution is easy: Remove the testService dependency from BarController. Whenever testServiceis accessed in BarController, it will use the appropriate getter of FooController and everything works.

In this simple example the problem is quite obvious and can be easily solved. However, if your classes become larger this can be a bit tricky to debug. Assume you have a base class with multiple sub classes. Whenever you want to add a new dependency to your base class, you have to check all the subclasses. If one of the sub classes already defines the same dependency you have to remove it or it will not be available in your base class.

Discover how the Force.com Web Services Connector (WSC) is a code-generation tool and runtime library for use with Force.com Web services, brought to you in partnership with Salesforce.

Topics:

Published at DZone with permission of Michael Scharhag, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

SEE AN EXAMPLE
Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.
Subscribe

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}