Terry, a few thoughts and also a possible solution for you.
1) First, when you say this is a security issue that "because of our security structure I cannot access the file structures directly from our development systems", are you referring to a remote server that has CF setup, and how you can't access the cfusion/wwwroot in that also?
And so then you add, "I am trying to set up the environment locally on the laptops and have the web files on a shared drive". By that you mean that you will setup a local CF dev instance (good), and rather than "put the code in the cfusion/wwwroot" there, you want instead to point to the code on a shared drive, right? That can indeed be done.
Again I'll say first that others solve that readily by just putting a web server on their local CF dev machine (whether IIS or Apache), and configure THAT to find the files on that other folder (or shared drive), and then finally use CF's "web server confiuration tool" to connect that site to the local CF instance.
2) That said, and back to my previous response about setting up Tomcat (and as Dave referred to in his subsequent reply), I'll say now that there's a solution I've used that MAY work for you. It's not about "changing CF to use another folder as its webroot" (as your original request sought).
Instead it's about adding to this Tomcat configuration what in other web servers would be considered a "virtual directory" or "alias" configuration. The goal for this would be that when you make a request for a given folder, like localhost:8500/bob/somefile.cfm, the web server would be told to find the code for that "bob" path in a given folder that does NOT need to be in that cfusion/wwwroot, where it would expect to find it by default. (Again to be clear, this is NOT about changing it to think that a request for / should find files in a location other than the cfusion/wwwroot, as that has broader ramifications.)
And at least one way to do that (in the modern Tomcat versions that recent CF versions support) is to use what's called a tomcat "preresource" definition, which can be put in the server.xml file of your CF instance (in the cfusion/runtime/conf folder). There are no such presources in there by default, as CF comes packaged. And if you're going to change this file, as Dave said be sure to back it up somehow.
Then in an otherwise stock CF server.xml file, at the bottom just above the closing </host> element, you could put in code like this (changing the paths pointing to CF to be correct for your own environment). Note how I have defined effectively an alias (a "webmount") for your /WebTest folder, telling Tomcat/CF that its files should be found in D:\mydir\wwwroot\WebTest:
<Context path="" docBase="C:\ColdFusion2023\cfusion\wwwroot" WorkDir="C:\ColdFusion2023\cfusion/runtime/conf/Catalina/localhost/tmp" >
<Resources>
<PreResources base="D:\mydir\wwwroot\WebTest" className="org.apache.catalina.webresources.DirResourceSet" webAppMount="/WebTest"/>
</Resources>
</Context>
Note also that the xml elements and attribute names are all CASE-SENSITIVE, even on Windows which is otherwise NOT. But the folder paths are not, nor even is that webmount value--on a Windows machine, I mean. One could request either localhost:8500/WebTest or localhost:8500/webtest (which may surprise some, because even on Windows Tomcat can be case-sensitive about some request URLs). I just followed your lead in the casing of those webmount and base attribute values for WebTest.
Once you put this code in place and restart CF (and assuming it comes up ok, and that as a test you can still acces your CF Admin ok), you should find you can now access the CF files that are outside the cfusion/wwwroot. I use this myself on all my machines, for accessing one particular set of files that I leave in Dropbox to access from within all my CF instances. In that case, the folder is not a "shared drive" in the classic Windows sense, but I think you should find this works--whether using a mapped drive or a UNC path, etc. Let us know.
Again, this "aliased path" approach is not the right solution for everyone (as they may not want to "have to define a bunch of these preresource lines for each top-level folder they need to access"). They may prefer then to really CHANGE what CF regards as the root--and that's where I said that could get sticky. I know Dave said in his later reply that doing it should not affect the CF Admin, but I really think it would. And again I've not yet done or seen anyone do that.
But I wanted to share it as an option, whether it works for you or may for others who later find this thread.
Finally, if the restart of CF fails (or testing of the CF Admin doesn't work), note how I had proposed those lines for a STOCK server.xml for CF2023 (though it should work as well for CF2021 and 2018, at least). If your server.xml for some reason had been modified already to have already an uncommented "context" element like I show, then mine above would be in conflict with that. Try putting just the resources elements inside that existing context elment you may have. (While a stock server.xml for CF has such a context line as installed out of the box, it's commented out by default.)
3) This approach is a pure Tomcat way to effect the sort of redirection that Dave was getting at with his consideration of using operating system hard links/symlinks. That can have ramifications beyond just the CF/Tomcat setup that some may be unwilling or unable to use. I hope the above might help.
4) As for your final reference to "using the remote servers" seems perhaps to be referring to a remote CF instance. Is that right? And might you be referring to how to setup CFBuilder to refer to that? If so, you can, but let's put that aside for now. If we first fix your local CF setup, that might inform how you or others may configure that remote CF servers (but perhaps it's already setup), but THEN we can tackle how to setup your CFB for both that local and remote CF instance (and the code, wherever it may be for those).
CF setup can be complicated enough for those who don't deal with it often. When you introduce multiple potential code locations, and dealing with both local and remote CF instances, that can fluster many. And when you add in trying to access all that in CFBuilder (which many struggle with out of the box, for various reasons), that can become quite a hornet's nest.
5) To my last point, I'll add that I do make my living helping people untangle such knots (in CF, CFBuilder, Lucee, and related things), whether for free here in the forums (along with Dave and many other helpful folks) or via remote screenshare consulting (carehart.org/consulting). If ever you run out of steam to power through things on your own and/or with our help, just know you don't need to "go it alone"...but I certainly understand that some won't or "can't" pay for assistance.
But let us know if the workaround above helps you.
/Charlie (troubleshooter, carehart.org)
7
Replies
AdChoices