Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

The most common mistake when using dependency injection frameworks

DZone's Guide to

The most common mistake when using dependency injection frameworks

· Java Zone
Free Resource

Just released, a free O’Reilly book on Reactive Microsystems: The Evolution of Microservices at Scale. Brought to you in partnership with Lightbend.

I’ve been answering spring and CDI questions on stackoverflow quite a lot, and what I notice as a recurring mistake (or misconception) is that people aren’t aware that they should not instantiate the objects in which they want their dependencies injected.

They assume that when they do Foo foo = new Foo(), the dependencies of Foo will be injected by spring. No, they won’t be. Here’s an excerpt from an answer of mine to such a question:

First, and most important – all spring beans are managed – they “live” inside a container, called “application context”.

Second, each application has an entry point to that context. Web applications have a Servlet, JSF uses a el-resolver, etc. Also, there is a place where the application context is bootstrapped and all beans – autowired. In web applications this can be a startup listener.

Autowiring happens by placing an instance of one bean into the desired field in an instance of another bean. Both classes should be beans, i.e. they should be defined to live in the application context.

What is “living” in the application context? This means that the context instantiates the objects, not you. I.e. – you never make new UserServiceImpl() – the container finds each injection point and sets an instance there.

So do not instantiate objects yourself. Configure them to be instantiated by spring (via xml, annotations or java config).

(FYI: there is a way of getting dependencies injected into objects instantiated by the user rather than by the container. It uses AspectJ weaving, in short: it makes bytecode modifications so that whenever an object is instantiated it gets managed by the container. But this is “black magic” and is not “on” by default. And it certainly isn’t supported in many DI frameworks)

 

From http://techblog.bozho.net/?p=423

Strategies and techniques for building scalable and resilient microservices to refactor a monolithic application step-by-step, a free O'Reilly book. Brought to you in partnership with Lightbend.

Topics:

Opinions expressed by DZone contributors are their own.

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

{{ parent.tldr }}

{{ parent.urlSource.name }}