I just created a bunch of simplified files and, lo and behold, I stumbled upon something.
I was copying the originals of the files and renaming the files by tagging an “_test” to the filenames.
The property with the inject attribute changed to property name=“utility” inject=“utility_test@api”; instead of property name=“utility” inject=“utility@api”;
I tested and got a good response back with the expected text!
So I have this saved. I started to back to see if I could pinpoint the trouble spot and found that when I change the property’s inject value of inject=“utility_test@api” back to the original inject=“utiulity@api”, the response outputs what belongs to utility_test@api and not the expected response from utility@api. This seems to suggest that the one or more cfcs are being cached. I have been using fwreinit=1 in the URL to reinitialize every time, however, it doesn’t seem to be working as intended.
Is the fwreinit=1 not working as intended in this case and do I need to understand some other refresh setting in order to refresh what appears to be a cached cfc?
I used to have it set as of last week, but commented it out and have been using the regular fwreinit=1 because it was too cumbersome during development to deal with the password.
I double-checked and it is already commented out for the reinitPassword line. I should be able to use fwreinit=1, correct? I also tried fwreinit=true, just for kicks, but I receive no difference.
Just keep in mind that when you change a reinit password, you must reinit one last time with the OLD password before the new one takes affect. Restarting CF will also clear it.
Also, note you MUST specify the reinitpassword setting, even if it is an empty string. If you completely remove the setting, you cannot reinit as a matter of security. We basically want you to be explicit if you don’t want to use a password to prevent accidental deployments to production with no password.
OK, I have no proven that it is definitely some sort of caching going on.
I restarted the service and then tested the result of the which utility response I would get back and now it is the expected response.
So, at this moment, I’m going to have to restart the ColdFusion application service each time I make a change to the cfc files.
I have just briefly looked at some of the cacheBox settings (I have never used CacheBox, yet and very new to it and everything ColdBox altogether) to see if there is a way to disable caching while on the development machine, but the small changes I have made don’t seem to do anything, so far.
If anyone knows what is going on with this, I would deeply appreciate your help.
Make sure trusted cache is not enabled. Restarting CF shouldn’t be an issue. I’d be tempted to say something is keeping your reinit from actually firing. Set up a file logger in logbox and you can form if the framework is reinitting. It should take a bit longer for a reinit request than a “regular” one. Also, CacheBox shouldn’t have anything to do with caching CFCs unless you are putting them in there yourself.
One final thing-- are you storing CFCs in the session, application, or server scope? Those would persist across reinits unless you cleared those scopes manually.
I just noticed your message after typing my last one. So, I will adopt your explanation. In theory, if I type a password of “1”, then I essentially will have fwreinit=1 as I would like, correct?
By doing this, I make sure that the Application, ORM & cached wirebox objects are completely fresh. Also saves me having to restart the ColdFusion service as well.
That is interesting. I JUST modified my boss’s code to something similar for a different application other than the one we have been working on except that I did not use a hash.
This is what I created in a different application:
this.name = listToArray(getCurrentTemplatePath(), ‘’)[3];
What this does it grab a specified folder name so that way we use it for the life of the application and it will always be unique to itself which is why I see you guys also using the getCurrentTemplatePath(), but you are hashing it instead. We actually read this.name for other things within the application.cfc. However, maybe it is not as good to use for refreshing as you are stating? We haven’t had any problems thus far, however, it doesn’t mean we possibly won’t in the future.
I took a look at the default this.name in the application.cfc for ColdBox and it has some of what you have which is this.name = hash( getCurrentTemplatePath() );
Would that be sufficient enough or is there a reason to prepend something similar to your “contentBox2…” text?
I use the date and revision for a reason in development, once you change the application name it is like you restarted the service and everything is reloaded / everything like I stated before.
What are you using the this.name for in your app, just curious. I would avoid it and maybe set an Application variable instead for what you’re looking for elsewhere in the code.
You nailed it, Andrew.
We use it to create the application.name
and we use it for the datasource name (for now)
The way the application folders are here are a bit different than what I am used to, which is always having the same path and folder name on each environment.
Here, they have a dev and qa environment on the same server and their naming convention is like d:\websites\appnamedev and d:\websites\appnameqa and production is d:\websites\appname
So, in this case, the names are always unique and most importantly unique on the shared dev and qa server so the application does not get mixed between each other while sharing the same ColdFusion server. With that in mind, I refactored the code on how the this.name was being managed because there was a ton of logic being processed on every hit just to figure out the name of this.name. So I reduced it to one line and since I always know it is unique in our case, it is used as the application.name and datasource to simplify that was there before just to come to the same conclusion. If we ever separate the sharing of the development and qa server and spun up another server, it will still not conflict since at this point, the servers would have their own ColdFusion servers and would never be able to conflict. It seems to work for us with given the environment setup we have, unless maybe you might see something I don’t?
Yeah I am trying to get my head around this setup and all I can say is wow, this ends up being a huge waste of maintenance.
You do know that ColdFusion can run as multi server instances, which have their own sandboxed stuff. You could very easily use instance1 as QA and instance2 as testing and another for development. But personally, I was cringing while reading that.
Andrew, yes I am aware of that, which is the setup that I had at my previous employer. We had 9 instances running there. I am working with the new employer and in talks to change a lot of the things here. One of them being this. I’m actually pushing for us to use Lucee and we will be implementing it in the near future.
