[coldbox-4.0.0] DSLDependencyNotFoundException when leaving id:-prefix out from inject string

[Antti Koskenalho]

I have page A, that contains 9 iframes and loads 9 instances of another page, page B. After a CF restart, usually 3 to 5 of those B pages fails to load, giving Builder.DSLDependencyNotFoundException-error messages. Rest of the B pages load just fine. 99% of the time I don't have any problems loading any of our web applications pages (including B pages if they are loaded "normally" and not through page A), but there is some occurrences of DSLDependencyNotFoundException's happening, although they are very difficult to reproduce. Therefore I'm lucky that I have page A now, as loading all of the B pages successfully through A page fails every time after a CF restart.

I noticed, that in wirebox manual's example, the inject string contained prefix "id:". I did a test and added the prefix to all page B handler's cfproperties service inject strings and then repeated the test. After adding the ids, all 9 out of 9 page B instances loaded without any problems (I tested this several times).

Here is the example code that failed: 

<cfproperty name="xxx_service" inject="xxxService@xxx_manager" scope="instance">

...and this worked: 

<cfproperty name="xxx_service" inject="id:xxxService@xxx_manager" scope="instance">

My question is, why does the one without id's work 99% of the time, but fails some times (under a heavy load perhaps?). Is it a suggested policy to add the id:-prefix? Could this be a misconfiguration of my CB/Wirebox?

I would be happy to hear any suggestions, comments or questions anyone may have related to this. I can provide more specific information if needed.

-Antti

[br...@bradwood.com]

Hi Antti, this appears to be some sort of race condition when the framework is booting up.  I'm not sure why adding "id:" is affecting it, but I'd need to see the actual full DSL dependency not found error, as what you gave us is about the same as telling your mechanic that your check engine light is on :)

 

Thanks!

~Brad

ColdBox/CommandBox Developer Advocate
Ortus Solutions, Corp

E-mail: br...@coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com 

 

 

--------- Original Message ---------

--
--
You received this message because you are subscribed to the Google Groups "ColdBox Platform" group.
For News, visit http://blog.coldbox.org
For Documentation, visit http://wiki.coldbox.org
For Bug Reports, visit https://ortussolutions.atlassian.net/browse/COLDBOX
---
You received this message because you are subscribed to the Google Groups "ColdBox Platform" group.
To unsubscribe from this group and stop receiving emails from it, send an email to coldbox+u...@googlegroups.com.
To post to this group, send email to col...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/coldbox/a12cc57f-9f7e-4611-854c-39c7e3f5750f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Antti Koskenalho]

Hi Brad,

Please find some of the typical error messages I keep getting as attachments to this post.

-Antti

[br...@bradwood.com]

Thanks,  that helps a bit.  Can you check and see if you have module auto-reload turned on (or any other auto-reload sort of settings).

 

The first two just show a model being injected from a module 

• id:Service1@Manager2
• id:Service2@Manager1

 

Assuming those names are correct, the only reason that should happen is if the framework is being reloaded at the same time in another thread and the module isn't loaded at that time.

 

The last three all have "id:id:etc"

• id:id:Service2@Manager1
• id:id:Service4@Manager1
• id:id:Service3@Manager1

 

This is a bug that's come up before, but no one has been able to tell us how to reproduce it.  It seems to happen when requests are hitting a server that's being reinitialized.  Maybe some logging will help you determine if your application is getting reloaded multiple times.

--------- Original Message ---------

To view this discussion on the web visit https://groups.google.com/d/msgid/coldbox/12807c7c-d96c-403f-a8ab-390ca4062fa7%40googlegroups.com.

[Antti Koskenalho]

Thanks Brad and sorry it took a while for me to reply.. I checked the autoreload settings (coldbox.handlersIndexAutoReload and modules.autoReload) and they both were set to false. Then I added log outputs to Application.cfc's onApplicationStart(), to onLoad() and onUnload() of each of the application's modules and to Coldbox's Bootstrap.cfc's onApplicationStart(). The application and modules were loaded properly, and only once, before the DSLDependencyNotFoundException occurred. At the moment I'm not sure what could I test next.

-Antti

[Antti Koskenalho]

I did a small experiment:

I added log messages to Builder.cfc (see attached file buildDSLDependency.txt) and checked the log outputs (see attached file log_output.txt). When DSLDependencyNotFoundException occurs, in the beginning of the buildDSLDependency method, the arguments.definition.dsl property does not contain the "id:"-prefix. But at the time the execution has reached the second set of log commands, the dsl property has changed, and now contains the "id:"-prefix. I tested surrounding the methods cfscript block with cflock and after that I didn't get any more exceptions with my test page.

I'm not sure if this provides any useful information to figure out the source of the problem or not, but this seems to work as a "quickfix" (although locking the method could probably cause problems elsewhere..). 

-Antti