CB7 and cbMailServices and Commandbox

[Andrew_Kretzer]

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).

[lmajano]

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

[Andrew_Kretzer]

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.

[lmajano]

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.

[Andrew_Kretzer]

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?

[Andrew_Kretzer]

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;

[lmajano]

@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.

[Andrew_Kretzer]

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?

[Andrew_Kretzer]

@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.

[lmajano]

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.

[danilosan]

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?

[lmajano]

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.

[Andrew_Kretzer]

@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…

[lmajano]

I’ll investigate this.

[West]

Was this ever resolved @lmajano or was a solution/fix put in place?