In our environment we have a single copy of coldbox and its modules used by many applications, via a base application CFC extended by each app cfc. For some reason when the CF service restarts and the application begins to initialize each application begins to throw stack overflow errors. The line number and specific message seems to change with each restart but its always a stack overflow and seems to be generally in the DSLspec or interceptor service. I can temporarily resolve it by doing an application stop in the on request start followed by returning false in the onapplication start, and then while the application is stopped clearing the component cache via cfadmin. Simply calling application stop or clear the cache alone has no affect, its seems to require being cleared while the application is stopped. Any ideas on where to go from here? This issue seems to be affecting only apps/environments that have been upgraded to coldbox 5 our 4.2 and 4.3 apps do not have this issue.
Do you have more than one app on this server using different version of ColdBox? If so, check you check and make sure “component caching” is turned off in the caching page of the CF admin? That setting is on by default but is very bad news if you have more than one version of a library in use.
We have one environment with only CB5 and one that is mixed 5/4.2/4.3 both have component caching turned off for sure, these are not new apps the issue seems specific to the CB5 upgrade. The issue exists in both mixed and CB5 only environments but only for CB5 apps
I ended up tracing this down to an issue with dependency injection, we were using wirebox to inject half a dozen services in a base class but the injected services were also extending this base class. For whatever reason it worked fine for the first few recursive injections but as the application grew and that pattern was copied we hit some threshold and it began throwing a stack overflow error. It just happened to coincide with the cb5 upgrade.
A stack overflow during injection is usually endless recursion. Probably a circular dependency. It’s possible that ColdBox 5 changed the order that the injections happened somehow that caused this. You could try using a provider, but you’d need to know where the recursion is happening. You can enable debug logging in coldbox.system.ioc via LogBox but it’s a lot of data to sift through. Of course, it’s always possible that it’s some sort of bug in CB5. If you can boil this down to a smallish reproducible example that you don’t think has any circular dependencies, than you can put in a ticket for Luis to look at.