Nat Pryce wrote "Dependency Injection Considered Harmful." He's an author of "Growing Object-Oriented Software, Guided by Tests," and he says that the problem isn't really DI, but the TERM "dependency injection" and how it spawns frameworks.
There are two aspects to Dependency Injection. Firstly, an object's interface should define the services that the object requires as well as those it provides. Secondly, the code that satisfies the requirements of an object by giving it a reference to the services of is collaborators is external to both the object and its collaborators. For this reason, the pattern also used to be called "third-party binding" or "third-party connect": some third party is responsible for connecting a satisfying a the service requirements of a component (the party of the first part) with those provided by another component (the party of the second part).
The name "Dependency Injection" only relates to the second aspect. And worse, makes it sound like dependencies are "injected" through the object's encapsulation boundary rather than explicitly defined as part of the object's API. And so we get "dependency injection" APIs, like that in JavaEE 5, which use reflection to poke dependencies into an object's private fields, bypassing the constructor, adding a great deal of complexity to client & test code while not providing the benefits that the Dependency Injection pattern should deliver.
It's an interesting thought: we see Spring and think "dependency injection" when we're doing a bunch of things, all sorta related to DI. According to Mr. Pryce, we manage context interdependency, we set up builders, we manage object state, we provide access and lifecycles, all kinds of things.
It makes the thought of dependency injection as a framework a little harder to compose. Spring might be doing the right thing when they split Spring into a million little bits - sure, we hate Apache commons for doing it, but it might be the right idea for isolating capabilities and stopping thinking of Spring as just "a depdendency injection framework" and starting thinking of Spring as a set of specific capabilities.