Testing an existing/mature application with Coldbox 7. I’m having a few oddball issues. One is where I have a model with cbMailServices 2.8.0+7 injected as such:
FWIW, I don’t have a COLDBOX_APP_MAPPING setup in Apllication.cfc (I think that’s where appMapping comes from?)
I also tried using the new cbMailServices delegate for CB7, but get the same error. I also turned off the transient cache in case that was making it wonky somewhere. I tried older versions of cbMailServices too.
Kicker: on another server that has same codebase, but using Tomcat fronted by Apache I don’t see this, just on two different local dev boxes using Commandbox (latest).
Thanks Luis, yes - I dove into the CB code and saw that as well. I will try to reproduce… I just know it works fine in CB-6 for years, only change is CB-7 and I get that issue.
So it appears that the startup() method in the Coldbox renderer never fires?
Cursory poking in CB source seems to show this somehow gets called by the LoaderService but I am honestly a bit out of my depth in understanding the CB plumbing at this point! Any pointers on what to check next or what would cause the renderer to come back w/o the startup() method being called?
@Andrew_Kretzer The renderer is a singleton and the startup fires by the loader service
// Rescan interceptors in case modules had interception poitns to register
services.interceptorService.rescanInterceptors();
// Rebuild flash here just in case modules or afterConfigurationLoad changes settings.
services.requestService.rebuildFlashScope();
// Internal event for interceptors to load global UDF Helpers
services.interceptorService.announce( "cbLoadInterceptorHelpers" );
// Startup the renderer for operation
variables.controller.getRenderer().startup();
// Execute afterAspectsLoad: all module interceptions are registered and flash rebuilt if needed
services.interceptorService.announce( "afterAspectsLoad" );
// Flag the initiation, Framework is ready to serve requests. Praise be to GOD.
variables.controller.setColdboxInitiated( true );
As you can see in the snippet above. It has to happen because if not the coldbox application is not initiated and can’t serve requests. I can’ replicate your issue.
Ahhh yes, that makes total sense. This setting is really a yank the cord kinda of event. I think the issue is that this might fire after the framework is loaded and thus removing built singletons. It’s tricky because this is a development only setting. I have to think about how to best circumvent this.
@lmajano the problem is that without this setting available in dev, every time you make a change to a model that’s a singleton (i.e. all DAOs, service objects, etc.) the changes do not take without a fwreinit which is a bit of a PITA and quite heavy-handed.
Too bad there’s not a way for it only apply to non-framework models? Or perhaps to ignore caching singletons in modules_app and model folders in the first place if in dev mode? Just spitballing…