Just been chatting with @micstriit, he has proposed the question, could we move to only supporting Application.cfc by default?
The old default setting “mixed” would of course be available, but for 99% of our users changing this would be beneficial (faster)
Why you ask? well Lucee has to walk back down thru the parent directories looking for Application.cfc/Application.cfm/onRequestEnd.cfm files which adds file system overhead.
I.e. for so myhost/one/two/three/four/index.cfm with an Application.cfc in the root, by default, Lucee is checking the file system in 4 directories for 3 different files, now it makes sense why we want to change this? (I can already hear you all running off to tweak your server configs!)
This would only affect people running ancient CFML
Most people have never changed this setting under Settings - Request?
Ehrm, you perhaps want to optimize something else.
Let’s say you have an application that walks through directories looking for files. Let’s suppose further that it costs the application significantly more resources to look for three files, F1, F2, and F3, than to look for one file, F1. So much so that you have to consider a breaking change from searching 3 files to searching just the one file.
Then a solution that comes to my mind is to optimize:
not the number of files to search, but the process of searching for a file.
“Faster”, “99% of our users” and, presumably, 1% of “people running ancient CFML” sound like prejudiced evidence to me. What are the three-file and one-file performance data? How many Application.cfcs and Application.cfms are there out there?
Take, for example, the “people running ancient CFML”. Do you have good knowledge of the number of CFML developers and websites originating from the 1990s and early 2000s that are still active out there? You will be surprised.
As I have argued, the reasons you have given are insufficient to warrant a breaking change. A breaking change is a big deal, very much a last resort. Though not necessarily negative, it is a break in the evolution of a system. As such, it can, if not handled carefully, lead to unintended, adverse consequences.
When considering a breaking change, take a leaf out of the book of the greatest designer, Mother Nature. At some point in Homo Sapiens’ evolution, more than 25 million years ago, Mother Nature decided it was time to do away with the tail. Wagging was no longer necessary. However, humans still carry vestigial remnants of a tail at the base of the spine, the tailbone.
I voted against but it’s because I’m lazy. And don’t have a lot of time to change a lot of code. I run an application written in the late 90’s plus one I wrote over the last untold number of years which are both in classic CFML code. The owner of the first app pays me to host it and it runs on and on and on. He does not pay me to refactor it. And I like to keep both running on the latest Lucee, OpenJDK, Tomcat that I can for security purposes.
However, should I move over to application.cfc for all my code? Well, yeah, of course. Will I? Only if I am forced to under pain of death. LOL!
For like 12 years, since my kid was born and that became my full time job, I keep saying I need to get with the new stuff kids these days are coding. But it can only happen if I can find some dedicated time to not be interrupted and allowed to focus for days, weeks, etc.
But as you said, it would be easy enough to change for the old style, so do what is best for Lucee becuase that matters more in the end to a healthy CF environment that any one person or groups preferences.
I have often thought about introducing a LUCEE_OLD_COMPAT=boolean flag or something similar, as we have a few of these old backwards compat defaults which suck for modern, secure development, i.e. scope cascading
One of the things I like about making Lucee faster is reducing our carbon footprint just a little bit more
I vote for avoiding breaking changes especially if it is only to speed things up. This change can introduce subtle bugs in old code that may be very difficult to find if you aren’t aware of this change. A stupid example is my main website has about 80 subdirectories. In the application.cfm i set a flag for if this directory requires you to be logged in and what level of permission is required.
Once I log in as an admin I get access to all directories. So when I go to test I might not notice that this system that has worked for over 25 years all of a sudden lets anyone access these directories because it is looking at the application.cfm from the home directory and ignoring the one in the current directory
It is easy enough to group all of those changes. Default to classic but allow selection of modern. Someone smart enough to understand the changes needed to make for this change would also be smart enough to know to select modern.
In your “stupid” example, the application.cfm in the root directory which would also be ignored…
We aren’t changing listenerMode, which you are describing as the problem (i.e. only my the home directory application.cfm being picked up instead of the one in the current folder, not just looking in the webroot)
Hypotheticals are one thing, why not try this setting change out with 5 or 6?
This is why we have Breaking Changes documentation
To paraphrase your “smart enough” comment, if you’re “dumb enough” not to read the Release notes and thus also see the Breaking changes document, whose fault is that?
Lucee 7.0 is not a minor point release, it’s a major release which also removes single mode, so if your code relies on multi-mode, per context config, you probably are going to need to make some changes anyway involving Application.cfc, or at least check.
Working on some defensive coding stuff to make life easier, using getApplicationSettings() and Web.cfc to check Lucee is configured as needed
What was reverted? This change, i.e. the thread header “Defaulting to only looking for Application.cfc in Lucee 7”? Or the ApplicationPathCacheClear? If the former, please state at the TOP of this thread, If the latter, why is this comment about this here in this thread? Just to clarify, as I voted FOR the change .
.