[coldbox-3.5.3] Issue when removing Setting from ColdBox Config

When the app I’m working on was first developed a year and a half ago, we placed a variable in the settings config of config/ColdBox.cfc. The intention was to use this setting by injecting it into services as needed, and it worked okay.
Now, I’m trying to refactor some code and remove that particular hard-coded setting in favor of a more dynamic approach. The issue I’m encountering, however, is that even if I remove the setting from ColdBox config AND from the one place it’s actually being injected into one of my services, I get the following error:

`
Error creating whatever. FWSetting flag is false The setting MyCustomSetting does not exist.

`

I’ve reinited, and even done a full applicationStop() (using the deploy interceptor). No matter what I do, I consistently get this error on the first request, and then on subsequent requests, it seems to resolve itself.
The only way to avoid the error seems to be restarting CF, which I’d prefer to avoid if at all possible.

I’ve banged my head against this one for a bit, so I definitely appreciate any suggestions anyone can provide.

Thanks!

Can’t say I’ve had that exact problem but something that has worked for me when a “can’t reinint” situation comes up is to use the administrator to flush the template and component caches.

Bob

Is trusted cache on? Wirebox caches component metadata, but that should be cleared on reinit. Is this the standard ColdBox injector, or one that you create yourself?

Also, where is the stack trace pointing to?

Thanks!

~Brad

ColdBox Platform Evangelist
Ortus Solutions, Corp

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

@Brad

No custom injectors, trusted cache is turned off, component cache is turned off.

@Bob-- I tried those, but no dice.

Here’s the trace:

Anybody have additional thoughts on this?

Thanks!

is it a module config that overwrites the parent?

Hi Aaron–

Nope, just a regular ColdBox site, no modules whatsoever.

Looks like either;

1. You are still referencing this variable somewhere in your application,
do another search to see if that is the case.

2. You have two applications using the same coldbox appName and or you are
sharing coldbox across multiple websites through IIS virtual directory
which depending on the order in which you fwreinit your application
"could/might" keep a coldbox setting cached. This has happens with our
applications in the past.

I have literally gone file by file, no other references to the setting/variable. I do have several apps that share the same coldbox, but each has an in-app mapping to it and they all have distinct application names.

I also upgraded this one app to use 3.7.0, just to see if that’s the issue, but I continue to get the same errors.

Is this a ColdBox or ContentBox application?

I have been hit with this that many times with ContentBox, that it is always fixed by clearing the cache and then reload the application.

If this is ColdBox are you using caching here, as it will more than likely be the issue. If not we have a problem Huston.

Hey Andrew–

My “problem” app is purely ColdBox, but I used the ContentBox example to show that it cuts across both. The issue seems to be present only when settings are injected into services which are extended by others. When I inject the setting into services which are not extended by others, and then remove the setting and reinit, everything is peachy. When I do the same for a service extended by other services, however, everything explodes.

However, if you continue to reinit for X number of times (where X appears to be equal to the number of services which extend the problem service), it eventually resolves itself.

If you go into coldbox/system/core/util/Util.cfc and trap the problem component in getInheritedMetaData(), you can literally see how the old, removed setting exists in the metadata, even though it’s clearly not in the component. It literally seems to only occur for extended services which have setting injects which are removed. I can reproduce it predictably for these kinds of services, but never for others.

Ok, I see what you’re saying now. Could the metadata for the parents be cached and not getting updated in this case?

I don’t think I know enough about wirebox to know what is actually happening here, can only throw suggestions around.

I’m in the same boat :slight_smile: Your suggestion appears to be what’s happening, so hopefully Brad or Luis can weigh in on this. Thanks Andrew!

Just tried this on Railo, can’t seem to replicate with the tests previously outlined.

Because Railo does not cache metadata. Cf does. It is a Pain in the rear but I have seen it lots of times where cf does not refresh the metadata of objects even if they Change.

Ok, so just a CF thing then? At least now I can stop pulling hair out :slight_smile:

Thanks Luis