After poking around in WireBox for a big there are two things I have noticed that I wanted to mention.
The autowire method in the injector never calls getMixerUtil().stop so all the inject helper methods get left around. It’s not anything killer, but I wanted to make sure it hadn’t just been overlooked. I can create a pull request if you wish.
The other item is much more important. Provider methods inject the host CFC with a hard reference to the injector via a public property called $wirebox. Also, the coldbox.system.ioc.Provider component is designed to store a hard reference to the injector in a private instance variable as well. In both of these cases aren’t we potentially widening the scope of the injector by placing hard references to it in the objects we are autowiring? I tested both provider methods and provider objects, and if I ask them to provide me something in the cacheBox scope, and then persist the host CFC in the application scope and reinit the framework, the provider in both cases throws the dreaded “Cache default is not registered.” error because the references to the injector (as well as the injectors references to cacheBox) have gone stale when the injector was reloaded on the init and should have gone out of scope. However, you have widened its scope by placing hard references to it in the provider CFC instances as well as CFC’s hosting a provider method.
Luis, just making sure this doesn't fall between the cracks. The
first issue might not be that big of a deal, but I would call the
injector scope widening behavior of the provider functionality (whose
purpose is to prevent scope widening in the first place) is a critical
bug in WireBox. I have ideas on how to fix it (along the lines of
what you showed me extending the ColdBoxProxy) but I would rather hear
back from you before going off and doing a pull request.
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!!
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.
As for the second comment there is a few things.
- Using provider methods, you inject a reference to the injector to then call the instance for you
- Using the virtual provider the object has already a reference to it.
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.
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:
<cfreturn instance.injector.locateScopedSelf().getInstance( instance.name )>
I got some time and actually finished this, Please check it from github and try it out. Again, scope registration MUST be enabled to leverage providers.