Application.cfc in virtual directory not being used

dev support
1

Originally posted here to address a different problem: Trouble getting web aliases to work - Communities - Ortus Solutions Community

I have a simple file layout for my app:

> project_root
   > tests
      > Application.cfc
      > runner.cfm
   > wwwroot
      > Application.cfc
      > index.cfm
   > server.json

and using CommandBox, I have a basic server.json file set up as:

{
  "web":{
    "aliases":{
      "/tests":"tests"
    },
    "bindings":{
      "HTTP":{
        "listen":"80"
      }
    },
    "webroot":"wwwroot"
  }
}

and I have configured a CF mapping for Lucee in .cfconfig.json:

{
  "CFMappings":{
    "/tests":{
      "INSPECTTEMPLATE":"",
      "PHYSICAL":"system/path/to/project_root/tests",
      "PRIMARY":"physical",
      "READONLY":"false",
      "TOPLEVEL":"false"
    }
  }
}

When I went to http://localhost/tests/runner.cfm, I noticed that the template in that virtual mapped directory (tests) was not using the Application.cfc in that directory. Instead, the Application.cfc file of the webroot (wwwroot) was being used. I was expecting the Application.cfc of the current directory to take precedence, so I’m a bit confused why this is. Is it related to Jira luceeserver LDEV-694?

Using with CommandBox CLI 6.1.0+813.

OS: Windows 10
Java Version: 11
Tomcat Version: 9
Lucee Version: 6.1.1.118 and 5.4.6.9

2

Try this on Lucee, not box.

3

Thanks for responding. I’m afraid I don’t know how to do that. I was directed here from the CommandBox community because the mappings and aliases are passed unmodified to the underlying engine (Lucee in this case).

From what I can tell, it’s a problem with being able to pick up Application.cfc because of its location in a virtual directory: the virtual directory doesn’t actually descend from the web root, so there isn’t a curr2root evaluation possible.

I’ve decided that this paradigm I presented isn’t what I want to follow anyway. Instead, I’m making the “/tests” folder a subfolder of the web root, and excluding that folder on the build/deployments. This eliminates the virtual directory and mappings necessary, and it doesn’t make jumping into developing the application any more cryptic.

So this is more a mild curiosity now, but of low priority.

4

Go here, download a copy of lucee and install it, run it.

https://download.lucee.org/

5

This might be a 6.x issue…

We appear to be having it in one of our apps… We’re using ‘normal’ files not mapped etc…

We’re using Docker here, so can quickly flip environments, but on 5.4.6.9 our code/app works fine.

Calls to /file.cfm runs the Application.cfc in that dir and calls to /dir/_another/_another/file.cfm runs the file /dir/_another/_another/Application.cfc so all is good.

Replace 5.4.6.9 with either 6.1.1.118 or 6.2.0.166-RC and calls to /file.cfm runs the Application.cfc in that dir but calls to /dir/_another/_another/file.cfm runs the file /Application.cfc. Dumping the onRequestStart arguments says the targetPage is /dir/_another/_another/file.cfm…

Not too sure what’s going on, as I’m still looking into this…

6

OK… this is an odd one, and possibly not related to the OP…

In our case we have our structure set up like:

app
   code
      Application.cfc
      file.cfm
   external
      common (lucee mapping called common)
         sharedfile1.cfm
         sharedfile2.cfm (etc)
   webroot
      Application.cfc (extends the code version)
      file.cfm (includes the code version)
      common
         Application.cfc (an actual file)
         file.cfm (an actual file)

In this particular case Lucee 5 will execute http:/blah.com/common/file.cfm fine

For Lucee 6.x it thinks the common sub-directory should map to the common mapping and is actually trying to execute external/common/file.cfm instead of the webroot version. If I rename the webroot common to something like _common then everything runs as it should. As there is no Application.cfc in this common area, that is why the root one is running.

Not sure why this differs between Lucee 5 and 6, but we’re going to rename the location and put an NGINX rewrite to fix the plumbing.

There’s a “Make this mapping web-accessible” that’s on by default… Which would explain what I’m seeing… Balls!

Ignore my rambling in this case…