"Containers are an abstraction over manually configuring the dependency
graph. They provide a high level language for managing the
configuration, composition and lifetime of objects." I understand this in principle, but I don't consider benefit worth the price. In Java, for example, we simply instantiate objects and pass them into each other's constructors. What actual benefit does this high-level language provide here?
Also, I rarely want to inject request-level services, so I can't think of a situation in which I want to inject a request-scope dependency. Can you describe an example of needing to do this? I tend to use Value Objects for request-scope input and I tend mostly to inject (apply partially) only Services (stateless when possible). Moreover, since injecting dependencies and apply functions partially means the same thing, I couldn't imagine wanting to apply something partially that would change from request to request: doesn't that defeat the purpose of partial application?
So I still miss something. I don't see in "Common configuration problems" a problem I have actually experienced. When would one ever inject a short-lived object, rather than merely always injecting ones with a longer lifetime? A short-lived object sounds like a request-scope function parameter to me.
I suppose I need to see an example of a code base using one of these containers so that I could debate with someone the merits of applying the container in a particular way. So far, everything I've seen---and I admit I haven't seen much---shows evidence of significantly not understanding the point of injecting dependencies.
Please keep trying, as long as you the energy to do so. :)