Why did we create DivineInject? Because dependency injection is important - but done wrong it can do more harm than good. DivineInject is opinionated about the right way to use dependency injection:
Constructor injection or death
Setter injection is bad for your health, just say no
Dependencies are singletons
Dependencies are external to your application - your DI framework doesn't need to know about users or sessions or threads.
Domain objects can be rich, too
Your domain model doesn't have to be anemic
Setter and method injection are much harder to get right - so DivineInject simply doesn't support them. If you can't implement your dependencies as constructor arguments, then maybe you should refactor the dependency so you can.
Dependencies are external to your application. Things like users and sessions are domain concepts in your domain, not in the domain of dependency injectors. All dependency injection frameworks get wrapped up in different scopes, which makes the frameworks harder to use. Divine Inject simply doesn't support them — if you need something user-scoped or session-scoped, then implement the logic yourself. It isn't hard, and if you ever want to understand the lifecycle of your objects it's in your code, not mine — which will make reasoning about your code or debugging it a million times easier.
DivineInject borrows an idea from Google Guice - with Guice it is called "assisted injection", in DivineInject we call it generated factory injection. The idea is the same — providing a simple way to create objects with constructors which accept runtime arguments as well as dependencies to inject. This allows you to create rich, stateful domain objects which also have dependencies.
Find out more about these ideas in the detailed getting started guide.