No, it doesn’t need to be called via the scope, though I’m picky about scoping variables so I asked. 
Using the explicit scopes can be handy for debugging situations like these. When I first started using Coldbox, I ran in to some intermittent issues like the one you’re dealing with, correct?
Just a quick thought:
I might be way off base on what follows, but are all of these missing injection errors happening with singletons? Since EngineService is a singleton, you’re bound to the application timeout before it would be instantiated again (which is also the case with Wirebox). As such, I suspect that Logbox (with this component) and your other injected properties are going MIA before the application timeout.
Since that auto wiring is being passed by reference, that could explain it coming up missing. I dug around in coldbox.system.ioc for a bit to see if I could figure out where and how Logbox is being stored (e.g. - Cachebox?), but I’ve got to run out so I couldn’t dig around any more. Brad or Luis would probably know if a disparity in your Cachebox Expiration vs Application Timeout (or a CF Server cache setting) could possibly affect this.
Good ideas, Jon. I’ll give the explicit scoping a try in the code we are seeing this in. I did not think to look at the CF caching configuration, and I’ll give that a shot, as well.
The idea of the application timing out is one I did consider; however I don’t think that is occurring as the problem just suddenly happens while the application is in use. In any event, it might be worthwhile adjust those application properties (I think applicationTimeout is set to 4 hours or so).
Thanks again and I keep my fingers cross on Brad or Luis tossing their collective expertise into the ring.
Kevin S. Anderson
Software Engineer
Intelligent Software Solutions Inc.
So no one spotted this then?
property name=“LOGGER” inject=“Logbox:logger:{this}” scope=“variables”;
It is variable and not variables, secondly it defaults to instance if I recall right and those both do the same thing.
No, “variables” is right. That’s also the default.
What line of code does the “logger is undefined” happen on? Is this CFC that’s being injected into a singleton or a transient. Can you provide a stack trace of the error and a Gist of the original file so the line numbers match?
There’s a couple reasons the logger could be null. The first could be that the case statement in LogBoxDLS.cfc is falling through to the end and returning nothing. (We should probably throw an error there). The second is that there could be a bug in that version of ColdBox. That sort of rings a bell. What are the changes of you upgrading to ColdBox 4.1 and giving it a go?
Thanks!
~Brad
ColdBox Platform Evangelist
Ortus Solutions, Corp
E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com
Your confusing persistence scopes with injection scopes. The doc you linked to are scopes that instances can be stored in inside of WireBox while after they are built. The “scope” attribute on property injection is the scope inside the actual injection target that the injected instance will be stored. It can be any expression that evaluates to a variable. “this”, “variables”, “instance”, “myrandomstructname”, etc. The last two of course, are really “variables.instance” and “variables.myrandomstructname”
Thanks!
~Brad
ColdBox Platform Evangelist
Ortus Solutions, Corp
E-mail: brad@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com
Yeah, I did get that confused.
I would be turning the logging on in the Coldbox config file, so that you can see why they are actually failing to be created.
Kevin,
If you dump out application.wirebox.getScopes().singleton.getSingletons() you can see all of your singletons. Logbox isn’t one and my recommendation would be not to inject non-singletons in to your singletons. Doing so could open up all sorts of issues, anyway (as noted in the docs: http://wiki.coldbox.org/wiki/WireBox.cfm ).
Since Wirebox exists in the application scope, I would just suggest injecting Wirebox in to your singletons and refactoring your calls for those non-singleton injected properties to getWirebox().getInstance(), etc. For the Logbox logger instance you could just call getWirebox().getLogbox().getLogger(this), which is more verbose but more reliable.
The other option would be to create a decorator for your singleton service objects with methods that should be inherited for all and helper methods or pseudo-accessors (e.g. getLOGGER()), which will handle the calls to Wirebox for what are now non-singleton injected properties.
Jon
That only applies to things that can be killed off, hence the scope widening problem. As they are cached in the Application scope there is no issue here.
Important : When storing objects in volatile scopes like cache, session, request, etc. You must be careful of not injecting them directly into singletons or other volatile objects as you could have memory leaks via a side effect called Scope Widening Injection. We recommend combining them via WireBox Providers to avoid this side effect.
Andrew,
Based on Kevin’s issues, The Logbox logger instance (and some other injected properties) apparently are being killed off before the singletons. It might be safer to inject Logbox itself (and then call the logger instance), but injecting logger instance seems to be causing nulls on the property. In either case, I know Brad suggested an upgrade to CB 4, which may resolve the issue in the long-term anyway.
Jon
Which is what I am trying to say, the logger is not a Singleton and is NOT stored in a volatile scope and is being injected into a singleton in the Application Scope. So the scope widening is not an issue here.
My advice is to turn logging to error, so one can actually see why it is not being injected.
It could even be as simple as being called from something that is using a different Application name, half way through the web request. Long shot, but can happen.