Copy link to clipboard
Copied
I have a Web, that use a symbolic link for centralized code.
The Application.cfm, stored in the original web-root, will not read from code
in the linked directory.
Thank you for your assistance.
Copy link to clipboard
Copied
You're gonna need to provide a bit more detail here:
* OS
* how you created the link
* how you're calling in the code
* what the error message is
* have you verified the user CF is using has permissions to the files concerned
--
Adam
Copy link to clipboard
Copied
Hi Adam,
thank you for your answer.
The web servers works under SuSE Linux 12.3, the link was first copied via a tar-archive
from the old server and then created new with "ln -s ../orgdirectory newdirectory".
It seems, that the Session-ID, defined in Application.cfm is not recocnized by cfm-templates
in newdirectory, which probably is stored in "orgdirectory".
There are several Error messages, that session-variables (SESSION.LANG for example) are
not defined. All these variables were defined in Application.cfm.
The Application.cfm is owned by the same user as the other cfm-Templates.
This code is identical functional at another server, working with CFMX7.
I had installed all patches, that offered by Adobe.
I'm frustrated.
Copy link to clipboard
Copied
I made an additional test.
A <cfabort> in Application.cfm will cause a Termination, if I call a cfm-Template in the server-root, but not, if I call a cfm-Template in the linked directory (newdirectory as described above)
Copy link to clipboard
Copied
Turn debugging on and look at the files listed in the "execution times" table. I suspect it will show a different - intermediary - Application.cfm being called.
--
Adam
Copy link to clipboard
Copied
Adam,
it seems to be a bug.
The "Application.cfc/Application.cfm lookup order" in the ColdFusion Administrator seems not functional as expected. I did several tests and it happens not only at symbolic links. This happens on every subdirectory.
Am I wrong, when I expect, that the "highest" Application.cfm found in a tree should be executed?
Example:
/
Application.cfm
aaa.cfm
!-----------------------------------------!
! !
"subdir1" "subdir2"
bbb.cfm Application.cfm
ccc.cfm
Settings in the ColdFusion Administrator
Default order:
- aaa.cfm: should execute the Application.cfm in root (/) only.
- bbb.cfm: should execute the Application.cfm in root (/) only.
- ccc.cfm: should execute the Application.cfm in subdir2 only.
Until Webroot
- aaa.cfm: should execute the Application.cfm in root (/) only.
- bbb.cfm: should execute the Application.cfm in root (/) only.
- ccc.cfm: should execute first the Application.cfm root (/) and then in subdir2
In Webroot
- aaa.cfm: should execute the Application.cfm in root (/) only.
- bbb.cfm: should execute the Application.cfm in root (/) only.
- ccc.cfm: should execute the Application.cfm in root (/) only.
Am I wrong with this?
In my case, only "In Webroot" work as expected.
Torsten
Copy link to clipboard
Copied
Yes, sorry, you are misinterpretting how the Application.cfc/cfm look-up works. CF will only ever execute ONE Application.cfm file: the nearest upstream one; where by "upstream" I mean it'll look in the current dir, then the parent dir, then the grandparent dir, etc.
The setting in CFAdmin means this:
* default: it'll traverse all the way to the root of the drive
* until webroot: it'll traverse only as far as the webroot
* webroot only: it'll only look in the current directory and then the webroot, but not the intermediary ones
But whichever option you employ, only ever the "nearest" Application.cfc or Application.cfm is used.
--
Adam
Copy link to clipboard
Copied
Hi Adam,
thank you for your support!
Ok, I agree to that, that only one Application.cfm should execute.
But in the options "default" and "until webroot" an Application.cfm will never executed from templates
in subdirs. This works only with the option "webroot".
In my webs, I can do this workaround to select "webroot only" and place the one and only Application.cfm
in the webroot. This works fine now.
But it seems to be a bug in CF10, that there is no search sequence to upper folders. Do you agree with me?
As I explained, I did several tests, and with the options "default" or "until webroot" selected, an Application.cfm
in upper folders were never executed.
Torsten
Copy link to clipboard
Copied
But it seems to be a bug in CF10, that there is no search sequence to upper folders. Do you agree with me?
No - I don't agree with you - because that would break pretty much every CF application on the planet. And we would have heard about that 😉 You're just doing something wrong, or your install is shagged (I suspect the former).
As I explained, I did several tests, and with the options "default" or "until webroot" selected, an Application.cfm
in upper folders were never executed.
OK, well I'm about to head out to the pub for lunch, so cannot look into this now. But depending on how comprehensive the "lunching" ends up being, I might have a look at this later today. Stay tuned.
--
Adam
Copy link to clipboard
Copied
Adam Cameron. wrote:
OK, well I'm about to head out to the pub for lunch, so cannot look into this now. But depending on how comprehensive the "lunching" ends up being, I might have a look at this later today. Stay tuned.
OK, sorry for the delay: had too much beer at lunch so was neither use nor ornament for the balance of the day once I got home.
However I've completed my investigation / confirmation of how all this stuff works, and have written a blog article about it here:
http://cfmlblog.adamcameron.me/2013/05/applicationcfc-look-ups-and-linked.html
HTH.
--
Adam
Copy link to clipboard
Copied
Hi Adam,
this explains everything!
I read your blog and understand right now,
that there is a difference between the system root
of coldfusion and the web root.
In my case, the webs are at a different location.
The system root of coldfusion is located at
/opt/coldfusion10/cfusion
and the web root is located at
/srv/www/<virtualhost>
Therefore I had misunterstood the options
in the Coldfusion Administrator.
With the option "webroot" everything works
as I expect.
Thanks once more for your support!
Torsten
Copy link to clipboard
Copied
Cool. I think the misunderstanding is probably more on the part of Adobe using the term" web root" when they mean something else. The CF root and thr web root will seldom be the same directory, so their docs are misleading (or just wrong depending on how charitable one is feeling).
--
Adam
Copy link to clipboard
Copied
This seems to be broken still/again, possibly due to a CF update, or possibly because it was always buggy in CF10. I have had no issues whatsoever in CF9 with the default lookup order.
I have the following directory structure ("webroots"):
/data/www/docroot
/data/mobile/docroot
/data/wwwdev/docroot
/data/mobiledev/docroot
And I symlink in the following cfc directories
/data/cfc
/data/cfcdev
Both www and mobile get /data/cfc and the dev sites get /data/cfcdev
Each of those docroots is a separate virtual server and I have setup the webserver connector to Tomcat.
Now, no matter which of the three lookup settings I try, the cfcs will not find an Application.cfc/Application.cfm
I read a similar issue early on in CF8 that was resolved with a patch to 8.0.1.
Any ideas?
Copy link to clipboard
Copied
Don't know if this will help, or not. I was searching for a way to get TLS/SSL to work with CF10 built-in web server, and ran across this:
Note: To enable OS Symbolic links after switching to Tomcat, edit the context.xml file found in /cfusion/runtime/conf/ to add allowLinking="true" attribute to the context element.
HTH,
^_^
Copy link to clipboard
Copied
Can you summarise the directory structure between the file you're calling and the Application.cfm you're intending to run. Also check whether there are any other intermediary Application.cfm files "upstream" from the file you're calling between that and your intended Application.cfm: if there is, your request will be running that insted of the one you want.
Another thing: if you output getCurrentTemplatePath() in the file you're calling, does it show the file being in the directory substructure of the symlink, or of its original location? I am guessing the former, but best to check.
--
Adam