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:
property name="mailService" inject="MailService@cbmailservices";
In a method I will then call it like this:
mailService.newMail(
to : getEmailTo(),
subject : "my subject"
)
.setView(
view : "Process/emailBody",
args :
{
auditTrail : listAuditTrail(),
sonumber : variables.sonumber,
toStage : toStage,
invoice : arguments.invoiceNumber
}
)
.send();
When this is hit, I continue to get this error:
Component [coldbox.system.web.Renderer] has no accessible Member with name [appMapping]
and it comes from here:
C:\dev\apps\myApp\lib\coldbox\system\web\Renderer.cfc:814
C:\dev\apps\myApp\lib\coldbox\system\web\Renderer.cfc:891
C:\dev\apps\myApp\lib\coldbox\system\web\Renderer.cfc:312
modules\cbmailservices\models\Mail.cfc:477
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).
Yes that doesn’t look like normal behavior, because the code for that is simply this:
variables.config.body = variables.wirebox
.getInstance( "Renderer@coldbox" )
.view(
view : arguments.view,
args : arguments.args,
module: arguments.module
);
So not sure how than can produce that error. We would need a way to reproduce it
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.
Yes, and you never know what regression you will discover 
ColdBox 7 is a major release, and you never know what could have broken. So please let us know if you can reproduce it.
I tried a clean app and slowly adding “complexity” similar to my app in question, but can’t seem to make it fail (yet).
So, back to my failing app, if I add this right above the code you list in Mail.cfc:
dump( variables.wirebox.getInstance( "Renderer@coldbox" ) ); abort;
I get this:
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?
So, moving the following to a generic handler that does nothing else except display a blank view page causes the same dump as above:
dump( getInstance( "Renderer@coldbox" ) ); abort;
@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.
Thanks @lmajano
Well, something is amiss because I just tried this:
public void function index( event, rc, prc ){
dump( var=getInstance( "Renderer@coldbox" ), expand=false, top=5 );
dump( var=controller.getRenderer(), expand=false, top=5 );
event.setView( view="home", layout="Layout.BS5" );
}
and I get this:
Not sure why those would be different… especially if it’s a singleton?
@lmajano OK, I have found the issue. Enabling this setting in dev is the culprit:
wireBox.singletonReload = true;
To replicate, create a new app: coldbox create app-wizard name=myApp using the default skeleton and dump the Renderer in Main.index:
dump( var=getInstance( "Renderer@coldbox" ), top=3 );
If you add the singletonReload setting to dev and reinit, the above dump shows all NULL values.
2 Likes
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.
I run into the same issue. After upgrading an older app from 6 to 7, I get th error:
Component [coldbox.system.web.Renderer] has no accessible Member with name [appMapping]
@Andrew_Kretzer
Do I get it right, by setting wireBox.singletonReload = false; you found a workaround? It did not work for me.
@lmajano Do you have any fresh advice?
Singleton auto reload has issues because the renderer is a singleton and started
Only once.
I would recommend avoiding that setting. I might deprécate that setting. Causes more issues than help.
@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…
