Defaulting to only looking for Application.cfc in Lucee 7 (rejected)

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?

The change would be to default to Modern

With CFConfig.json it’s a one liner to revert to the older, slower default

{
    "listenerType": "mixed"
}

It would of course be flagged in our breaking changes documentation

  • It’s 2025, do it
  • No this is a bad idea
  • What’s Application.cfm???
0 voters

anyone against the proposal, please share your rationale below as a comment, we’re interested in hearing your opinion

Love this idea, time to move forward.

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.
1 Like

We have been progressively optimizing lots of little things in Lucee, which all add up over time.

Adopting modern defaults benefits everyone

I don’t really understand your objection TBH? Even if I did, I’d still say, ok let’s do both then!

but I know how the internals of Lucee work, there’s no magic fairy dust, @micstriit is a java guru

It’s a simple change if you want to stick with old code style

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

It’s a simple change if you want to stick with old code style

“Simple”? You mentioned a breaking change.

Simple, documented config change!!!

Are you just arguing for arguments sake? sure feels like it

If this was a stand up, the scrum master would probably say thank you, but the rest of the team (see poll results) have decided

Also Happy Birthday Application.cfc it was introduced 20 years ago in MX7

1 Like

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 program like its 1999 (CFTAGS all the way)

I do not see the big deal about having to set in the admin section "MIXING TRUE vs defaulting it.

Yeah, I definitely need to update my coding.

A few people have asked about how to make the this faster by avoiding so many look ups.

Lucee already a range of optimizations available for making source code interactions faster.

  • inspect never (prod mode)
  • ListenerMode, as per the screen shot, let’s you say, Lucee, only look in the webroot for the Application.cfc

ListenerMode and ListenerType can be also configured per mapping

As for migrating old code, this is a great use case for AI

Here I just pasted in the example code from https://helpx.adobe.com/coldfusion/developing-applications/developing-cfml-applications/designing-and-optimizing-a-coldfusion-application/using-an-application-cfm-page.html

https://www.perplexity.ai/search/convert-this-application-cfm-t-To61Ee_zTzugd9fK8p20QQ#0

1 Like

Thanks everyone for their input, we’ve gone ahead and have made this change in 7.0.0.143

We are doing the final clean up and testing before the first 7.0 BETA

I have added a note to the CFAPPLICATION docs and this will of course be noted in the Breaking Changes document for 7.0

2 Likes

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.

1 Like

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

https://luceeserver.atlassian.net/browse/LDEV-5442

1 Like

This whole conversation made me realize that I need to get to know the Lucee admin better.

I’m fortunate that I only have a few places to make the change to “modern”.

So, we did some benchmarking around this change and found the gain was minimal, partly due to some additional caching added in 5.3.8,

There is a 20s cache for these lookups

As seen under Settings - Performance/Caching

so we have reverted this change

The admin is a guided tour of features in Lucee, which is all written out to the lucee-server/CFConfig.json file

Arguing just for the sake of arguing? I didn’t say anything you don’t already know.

A “breaking change” is a change that breaks backward-compatibility. Software changes don’t get more major or more significant than that.

If this was a stand-up, a comedian would say, " Why did the breaking change cross the deployment pipeline?..
To roll everything back to yesterday. "

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 :wink: .