Strange behaviour cfinclude with CF11 and Yosemite

[gghordijk]

Hello,

I have a strange problem with my includes, if i save my file with changes, CF can't find them anymore.

Example:

<cfinclude template="views/file.cfm">

Is working fine, when i change something and save file.cfm, I receive the following error 'Could not find the included template views/file.cfm.' which is strange, because the filename and location did not change.

Changing the the cfinclude and the filename into 'file1.cfm' does work. Which made me think it had something to do with caching, but clearing the cache and restarting CF did not work.

Do anyone have an idea?

Thanks,

G.

Running

OSX 10.10

CF 11 Upd 2. Dev

[gghordijk · Accepted solution]

It took me almost half a day...

The clear-cache-buttons did not do the job, but when I unchecked 'Save class files ' and restarted CF the problem was solved.

[BKBK]

Thanks for sharing your finding.

[Carl Von Stetten]

gghordijk,

That is expected behavior.  In CF Administrator, that setting has an explanation right below the checkbox:

When you select this option, the class files generated by ColdFusion are saved to disk for reuse after the server restarts. Adobe recommends this for production systems. During development, Adobe recommends that you do not select this option.

So on your development box, leave this unchecked.  On your production server, checking it will allow your applications to load faster after a reboot (it won't have to recompile the CFM/CFC files into classes again).  If your development and production servers are the same machine, then you will have to leave it unchecked and sacrifice the improved performance on the production side.

-Carl V.

[Nando_Breiter]

Carl,

I disagree that a "cannot find template" error is expected behavior. How does saving a class file to disk equate to ColdFusion not being able to find templates that are obviously there??? And how am I supposed to figure out from the error message what the underlying problem actually is? "Bloody well look, dammit!! It's right there in front of your nose!!!"

I ran into this yesterday on a CF11 production server that has been up for about a month. It seems the Save class files option was checked by default on install, because I didn't change any settings in the Caching section, assuming, as usual, that the defaults would be not to cache in a way that would make the server "un-updateable". I've been updating files here and there on the server for weeks as compatibility bugs are exposed or changes are requested. Suddenly, out of the blue, CF could not find a template I had updated, and it broke the entire application. Logins were no longer possible. This behaviour was neither expected nor desired, and there is nothing in that text that warns developers that any time they make a change to a production template, this box must be unchecked and the server restarted. I had absolutely no clue that the problem could be related to an admin setting. I ran through permissions issues, hard disk failure issues, considered cloning the server, wondered how the fact that I had just installed SSL certs might have somehow caused CF to not find a template I had just changed, looked a permission issues again, checked and rechecked which user CF was running under, planned how I was going to roll back the entire application to CF9 and shift the data that had changed, thought about switching to Railo and telling my clients they simply have to bear with me while I work through some compatibility issues ...

I expect options for production systems to make CF more performant, stable or secure. Options that take production applications down with no warning, rhyme or reason are neither expected nor welcome. Given that I now am fully aware of the consequences of checking this box, I would recommend leaving it always unchecked. Otherwise, every time I need to make a minor change to a production server I have to uncheck it, reboot the server, make my change, check it again, and apparently reboot the server again. How does that improve the experience of my users? And if I somehow forget this arcane procedure, whatever it actually is, and take the app down again, it's even worse!

[Carl Von Stetten]

@Nando,

I think you are correct about expected behavior **in this case**.  Overall though, the setting is intended for a production server where code is not changing or expected to change **during production**.  Thus, if you do make code changes, they may be ignored because with this setting turned on, ColdFusion Server will ignore your source files (if they already existed) and go straight to the compiled class files.  The exception is when the edited file is new, in which case ColdFusion Server will generate the class file on first request.  This setting can improve overall performance, especially on applications with large numbers of files.

gghordijk,

The reason clear-cache didn't work is because that will delete cached templates, not class files.  I'd recommend reading this page for a detailed explanation, particularly the section "Application Server Caching".

-Carl V.

[Nando_Breiter]

@Carl,

The code change I made to an existing template was not ignored. That would have been somewhat more acceptable. The code change caused a "cannot find template" error to be thrown that broke the entire application, making it unusable. Even the error itself should be considered a bug, on the face of it, because the template was in the correct location, the same place it has been for the last, what, 3 years. The operating system had no trouble finding and reading it.

In any case, I filed a bug report here: Bug#3917793 - Option Save class files causes CF to break applications if templates are modified. Please vote for it if you are so inclined. Bottom line for me is this feature should not break applications like this, especially if the option is selected by default on install and the consequences are not explained upfront.

[Carl Von Stetten]

@Nando,

I'd love to vote it up... if the bugbase wasn't down again.

-Carl V.

[Carl Von Stetten]

@Nando,

I was contemplating this some more.  I thought maybe since class files contain path references to the included template's class file, the revised included template's class file might have been given a new name which somehow broke the path.  I checked this theory with a very small test application on the CF11 that is bundled with CFBuilder 3 (after applying update 3).  The name of the class file didn't change when I edited it.  So that theory was busted.  I think you definitely found a bug.  I'm voting it up now.

-Carl V.

[jbrock777]

Hello G,

   I recently ran into this same issue on RHEL 7 with CF2016.

   The issue was the ownership of the compiled class files stored in wwwroot/WEB-INF/cfclasses had been set to root:root during the last hotfix I applied.

   A restart of the instance caused everything to work great since the trusted cache has not warmed up - however, as soon as I clear the template cache - bam, missing include files...

   In my cfadmin settings I have "Trusted Cache" and "Save class files" options enabled.

   If Trusted Cache is unchecked - the behavior goes away with new Class files being generated after clearing template cache if they are not found in cfclasses.

   The better solution however IMHO is to just fix the file permissions.

   Adobe really should be throwing a better error than the filesystem include is missing.  I will be filing a bug report for cf2016.

~J

[Charlie Arehart]

Thanks, J, for that clarification. Very helpful to seemingly explain what was amiss for G and Nando, (a bug in a hot fix, changing permissions on the files in cfclasses).

I see your reply here was from 2017  while theirs were in 2014-15. I'd love to hear if they'd noticed and confirmed this.

I realize they may have just left things with "save class files" off and never looked back. But it would see to counter the assertion that this was a fault or indictment of that option. Instead  it was just a factor in the observed error, not seemingly the root cause.

But I'd love to understand more, if anyone ever did or does investigate further.