Configuration of a Dependeny Injection container

Hey! First post for me but long time reader of Stackoverflow.

Anyway, got a tricky problem wich is getting on my nerves. It's questions about how configurable should a DIC (Dependency Injection Container) be. I'm working on a session handler for our framework we are setting up. The session handler is dependent on a storage service, some simple configuration parameters and is the one that generates a session id with a salt.

Session handler is loaded by our container wich takes all the settings, either as a configurator object or an array of parameters. The container checks the setting for what storage service is called for and loads the service and injects it to the session handler. The storage service does not take any constructor settings at the moment.

Session handler in it's turn generat开发者_StackOverflowes the session id from the settings it got injected. And from there injects the session id and other settings relevant to the that storage service.

My questions are:

1. Is it proper to let the Session Handler inject settings to storage service? It's like a 2 step rocket.
2. Should I inject the session id and other parameters from start when I load the storage service in the container? Wich in the end leaves me with the problem of generating the session ID and have to rely on the storage service to do it.
3. What problems would arise if I did either way from above proposals?
4. Am I breaking anything "holy" :)

I am a bit confused by this part:

Session handler in it's turn generates the session id from the settings it got injected. And from there injects the session id and other settings relevant to the that storage service.

You already said that the session handler is dependent on the storage service. It would be a bad idea for the storage service to also have some dependency on session handler, because then your initialization process is way more complex and error prone than it needs to be.

So here's the question: what settings does the storage service need from the session handler? Can you remove any or all of these dependencies from the storage service? If so, you should do so.

As a practical example: let's say the storage service supports storage of data as named blobs (which may be implemented as files, or as rows in a database table, or whatever else). You use a name dependent on the session id to store the session data. What you need to do is not tell the storage service what the session id is, but have the session handler remember it instead and provide that information to the storage service only whenever it uses storage functionality.

In other words, try to keep your data grouped logically. Is there a specific problem that prevents you from doing so?