Sorry Brad, I am out of office this week on site at a client, that’s right Ortus is now my full time gig for now, so I am available for hire!! 
That’s cool. No prob on that.
Anyways, I don’t call stop because I find it unecessary to remove the mixers if I can reuse them. That is why I don’t remove them.
Fair enough. As long as it’s that way for a reason and not an oversight.
Again, I see your point about the excetion and the only plan of attack is to use the scope registration data to talk to the injector via the scope registration. In other words, in order to use the providers, the injector must be persisted in a scope via the scope registration.
That makes sense. basically, if you want to be able to find the injector without having a hard reference to the injector, it must be persisted in some pre-defined location. If WireBox were always part of ColdBox it would be easier. You could just get the controller out of the application scope the same way that the ColdBoxProxy does and ask it for WireBox. However, a custom implementation of WireBox could place the Injector anywhere they wanted.
I am thinking of doing another method on the injector like this: locateScopedSelf() which will get the scope registration data and get the injector from the persisted scope. So the Provider object would be updated to something like this:
That makes a bit of sense, but what object is “instance.injector” an instance of? It can’t be the injector itself or you will have a chicken-and-egg issue. There will need to be an prior “agreed upon” scope and key that the injector will be placed that the providers look, or the providers will need to be injected at autowire with the location of the injector in a variable that can be eval’ed to produce the actual injector reference when needed.
This de-coupling stuff is tricky!
~Brad