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

Learn how to build stream processing applications in Java-includes reference application. Brought to you in partnership with Hazelcast.

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

Learn how to build distributed stream processing applications in Java that elastically scale to meet demand- includes reference application.  Brought to you in partnership with Hazelcast.

Topics:

Opinions expressed by DZone contributors are their own.

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

{{ parent.tldr }}

{{ parent.urlSource.name }}