I am getting an error in wirebox injection in which it can’t find the requested dependency. We use one main application but we do have Scheduled Tasks and other small applications that depend on these models so this is the need for the mapping. Is this error the result of the mapping fail or is wirebox?
I imagine the best solution would be not to use a mapping for wirebox, but then how do i call this model from outside of the application. Thanks in advance!
RESULT:
detail
The target requesting the dependency is: ‘setup.QuickBooksDAO’
Message
The DSL Definition {JAVACAST={null},NAME={UserSession},ARGNAME={},DSL={id:id:erspmodel.UserSession},VALUE={null},REQUIRED={false},SCOPE={variables},REF={null}} did not produce any resulting dependency
tagContext
1st Template Line 164 at \coldbox\system\core\util\Util.cfc
2nd Template Line 370 at \coldbox\system\ioc\Builder.cfc
3rd Template Line 594 at \coldbox\system\ioc\Injector.cfc
The CF mapping makes no difference as long as the path to the CFC is resolvable.
If you can do new erspmodel.UserSession(); without issue, then that should work.
I do find it interesting that your error message added “id:” twice to the model path:
DSL={id:id:erspmodel.UserSession}
That doesn’t seem correct though I’m not sure how it would happen. The correct DSL is id:erspmodel.UserSession, and we add the “id:” bit if necessary but it shouldn’t get added twice.
Perhaps you can start debugging to ensure your CF mappings work correctly. Dump out the results of directoryList( ‘/erspmodel’ ) and make sure ‘UserSession.cfc’ shows up in the list. Also, eliminate the cfproperty by just trying getMode( ‘erspmodel.UserSession’ ) to test.
Even though it seems like what you are doing should work you could try another approach such as adding an explicit WireBox mapping in your /config/WireBox.cfc.
map( ‘UserSession’ ).to( ‘path.to.UserSession’ );
Then you can just refer to your model as “UserSession”.
The code sample changed a bit there. Are you using cfproperty injection or getinstance()? Also, you’re saying this only errors sometimes?
Is there a chance the non-framework page could be hitting ColdBox while it’s reinitting? Are the ColdBox reload checks run on every page to make sure ColdBox is loaded in case the legacy page is the first one to get hit after the server starts up?
Can you include the full stack trace so we can track exactly what methods were called and in what order?
We have a page (Outside of framework) called PlanHeader.cfm that has this call:
<cfset LOCAL.quickbooksDAO = APPLICATION.cbcontroller.getWireBox().getInstance(‘setup.QuickBooksDAO’)>
<cfset LOCAL.quickbooksObj = LOCAL.quickbooksDAO.load(obj = APPLICATION.cbcontroller.getWireBox().getInstance(‘setup.QuickBooks’))>
Inside the QuickbooksDAO (Now inside framework) we are calling UserSession through a mapping using a cfproperty
The error is not duplicated on local and this doesn’t happen all the time on production.
We only reinit on release days and the error is occurring on every day, other than if the framework can reinit itself?
We do use reloadChecks() on our onRequestStart()
So the error is coming from Builder.cfc Line: 374, but i can see where the id:id: would fail:
In Builder.cfc: buildDSLDependency function calls getModelDSL (Since it falls into a Custom DSL) with the definition of id:id:erspModel.UserSession and since the len(thisType) = 4 this does not fall into any of the cases, and the model name is not returned.
The real question is how do you think id:id: gets created?
What I would have done was exposed the QuickBooks as Restful API calls in a SaaS approach, much cleaner and easier to maintain and you would not be having to hook into calling a framework like this which causes issues as your finding out.
Andrew I definitely agree on the API call, and that is what we want to get to, but we have to move there in steps. We are migrating more and more to coldbox and consolidating our queries in models to allow us to do just that.
Im going to try some load testing to see if i can duplicate the id:id: issue, because i think that is the best lead I have.
Ok, so after a long time dealing (Mainly on release day) with this we have some renewed effort internally to try to help solve this problem.
We have still not been able to duplicate this locally but are trying with some load testing. (Possible concurrency in buildDSLDependency in the id:id?)
We had idea that I would like to toss out there about reloadChecks()
Brad. You mentioned reloadChecks() being fired each coldbox request. But we currently have about half of our application in coldbox, half in home grown framework. So from the beginning since we started with coldbox we have had this wrapped around reloadChecks().
Any foreseeable problems with calling reloadChecks() on all requests, even non coldbox ones?
Note: Homegrown framework being passed through admin.cfm, so this would not fire.
Since the APPLICATION.cbcontroller.getWireBox().getInstance() call comes from a non framework page, then reloadChecks is infact not being fired and we receive the resulting dependency injection.
I don’t think there’s an issue calling reload checks, but there might be an issue if the app is reloading over and over. Perhaps put an afterConfigurationLoad interceptor that logs someting so you can keep track of how often the app is reloading.
While we do have pages outside the framework accessing models via APPLICATION.cbcontroller, these calls are not always the source of the error. Also, it is not consistent to the particular model, nor handler instantiating the model.
On Monday in the middle of the day, without any framework reinits, we started getting this dependency injection error:
The DSL Definition {JAVACAST={null},NAME={QuickBooksDAO},ARGNAME={},DSL={id:id:model.setup.QuickBooksDAO},VALUE={null},REQUIRED={false},SCOPE={variables},REF={null}} did not produce any resulting dependency
The error on Monday was on a coldbox page, and not being called via APPLICATION.cbController. This error would occur every time the user tried to access that page, as if the bad dependency was cached. Our process when this happens is to take that server out of our load balancer, reinit coldbox, and put it back in (hoping we don’t get another dependency injection error). Our application is pretty much under steady load all day, so there wouldn’t have been an application timeout (our timeout is set to 1 day in application.cfc)
I was able to somewhat reproduce the error using a jmeter load test, but not exactly. While I do get some dependency injection errors while reiniting during the load test, they don’t persist, and the DSL does not have the double id:id:model…
Getting closer. I’m now able to exactly reproduce the error, and the error persists until a subsequent successful reinit.
The difference was that in all of the models used in the jmeter test, they were all injected using the model.foo instead of erspmodel.foo. Once i changed one of the models to inject using erspmodel.foo and reinited under load, i got the error with the double id:id. The erspmodel causes the buildDSLDependency function in Builder.cfc to fall into the default switch case (line 345).
I’m thinking that adding a wirebox mapping to the directory erspmodel (which is actually mapped to the /model director for use in a different coldbox app) might help.
Is “erspmodel” one of your Wirebox scan locations in config.Wirebox.cfc?
If it is, do you still receive the same error when you use “model:QuickbooksDAO” or “QuickBooksDAO” in the inject attribute of the property?
One other thing? Are any of these injections throwing errors singletons or using custom storage scopes. The same can be asked of any injected properties in the injected objects, and so on…
I’ve seen the types of error you’re receiving from an object going missing from within a storage scope or from a singleton being injected with a transient object. Based on the fact that the error you’re receiving seems to persist until framework reinit, I suspect there’s a singleton somewhere in the chain that’s causing the issue.
An update - we seem to have resolved this. We just created a custom DSL namespace in our wirebox config and refactored all of our injections to explicitly use the new namespace. We pushed the code out this week and have not had any of the errors we usually have when updating our production code (knocks on wood).
Brad - the error did not necessarily occur on a file that changed. It seemed to happen randomly, and only when there was load on the server. This leads me to believe there was some concurrency problem in Builder.cfc, specifically when the buildDSLDependency function lands in the default case, that was adding the double “id:” to the namespace. By explicitly referencing the namespace, we seem to avoid the problem.
Jon - none of the injections were singletons or using custom storage scopes.
Thanks to everyone that responded. The help was greatly appreciated.