The Most Common Mistake When Using Dependency Injection Frameworks

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)

6 thoughts on “The Most Common Mistake When Using Dependency Injection Frameworks”

  1. Il loved the “black magic” word ๐Ÿ™‚

    To complete the formula of this black magic, it’s interesting to notice that such bytecode modification (i.e. constructor modifications) isn’t supported at runtime, that’s why an AspectJ agent must be deployed on the JVM.

  2. @Bozho sorry for offtopic, but is it possible that you dont’ have an RSS feed?

  3. @waddle you can also use compile time weaving which makes life easier when working in your workbench (eg eclipse)

Leave a Reply

Your email address will not be published.