Skip to main content
B
bell_the_cat
Inspiring
February 26, 2025
Answered

ColdFusion 2023 Instances not using isolated Mappings

  • February 26, 2025
  • 2 replies
  • 804 views

I am running an environment with a ColdFusion 2023 application on one instance (call it Prime) and two additional instances set up as developer copies (Dev1 and Dev2).  Each instance points to its own copy of the application source repository, so developers can work on their own isolated copy in their Dev sandboxes and restart or whatever without affecting the Prime instance.  

 

Each instance maps /component_root to the appropriate local repository location in Server Settings for that instance:

 

Prime--> /component_root = /prime/wwwroot/component/

Dev1-->  /component_root = /dev1_repository/wwwroot/component/

Dev2--> /component_root = /dev2_repository/wwwroot/component/

 

The code is supposed to use the mapping to call the correct version of the component for the instance:

 

<cfset variables.SomeComponentCFC = CreateObject("component", "component_root.SomeComponent") />

 

However, what I'm seeing is that ALL instances come up with the Prime mapping, so the Dev1 and Dev2 code is throwing access errors since Prime repository location is not in their sandboxes.  

 

Is that how it's supposed to work?  Shouldn't the instances be truly isolated?

    Correct answer bell_the_cat

    A test:

    • Store the following code as the files, somePage.cfm and SomeComponent.cfc, in each of the 3 folders /prime/wwwroot/component/, /dev1_repository/wwwroot/component/ and /dev2_repository/wwwroot/component/
    • For each instance, launch somePage.cfm in a browser.
    <!--- somePage.cfm--->
<cfset variables.SomeComponentCFC = CreateObject("component", "component_root.SomeComponent") >
ColdFusion Instance root directory: <cfoutput>#variables.SomeComponentCFC..getInstanceRootDir()#</cfoutput>

     

    <!--- SomeComponent.cfc--->
<cfcomponent> 
	<cffunction name="getInstanceRootDir"> 
	
	<cfreturn server.coldfusion.rootDir> 
	</cffunction> 
</cfcomponent>

     

    Each time, the result should be the root directory of the instance


    OK problem solved!  I got a clue when I shut down the Prime instance and started seeing errors on Dev1 and Dev2, which told me I had a config issue with app isolation.

     

    Turns out in the Apache config, my VirtualHost instances were not referencing the correct uriworker.properties file for the linked CF server Dev instances - they were pointing back to Prime uriworker.properties.  After correcting and restarting, everything is working as expected.  So, user error, darn it.

     

    Thank you @Charlie Arehart and @BKBK for your help!

    2 replies

    BKBK
    Community Expert
    BKBKCommunity Expert
    Community Expert
    February 26, 2025

    Sometimes ColdFusion does not faithfully carry over settings when you create additional instances.  That may be the cause of the issue.

     

    The following assumptions will help in my explanation. Suppose that 

    • Prime is the main, original instance, and it runs on port 8500;
    • instance Dev1_Repository runs on port 8501;
    • instance Dev2_Repository runs on port 8502.

     

    These assumptions mean that you can access the 3 different ColdFusion Administrators via the respective ports. For example, on my server, the URLs would be:

    Prime ColdFusion Administrator: http://127.0.0.1:8500/CFIDE/administrator/

    Dev1_Repository ColdFusion Administrator:  http://127.0.0.1:8501/CFIDE/administrator/

    Dev2_Repository ColdFusion Administrator: http://127.0.0.1:8502/CFIDE/administrator/ 


    When you create additional instances, such as Dev1_Repository and Dev2_Repository, there are two things that ColdFusion does which are relevant to your situation:

     

    1. ColdFusion uses the contents of /Prime/bin/jvm.config as the basis for creating the respective JVM files /Dev1_Repository/bin/jvm.config and /Dev2_Repository/bin/jvm.config;
    2. ColdFusion uses a copy of the settings Server Settings > Mappings from Prime's Administrator to create the settings Server Settings > Mappings in the Administrators of Dev1_Repository and Dev2_Repository. 

     

    Hence my suggestion:

    • Check the contents of /Prime/bin/jvm.config, /Dev1_Repository/bin/jvm.config and /Dev2_Repository/bin/jvm.config. Ensure that none of them contains an unexpected setting or refers to an incorrect path;
    • Check the settings Server Settings > Mappings in the Administrators of Prime, Dev1_Repository and Dev2_Repository. Ensure that, in each case, the paths pertain to the relevant instance. 
      In particular, look out for erroneous settings such as the following:

      Dev1_Repository Administrator (Server Settings > Mappings) : /component_root = /prime/wwwroot/component/

      Dev2_Repository Administrator (Server Settings > Mappings) : /component_root = /prime/wwwroot/component/

      Where necessary, edit the instance settings, respectively, to

       

      Prime Administrator (Server Settings > Mappings) :
      /component_root ={ABSOLUTE_PATH_OF_CF2023}/prime/wwwroot/component/

      Dev1_Repository       Administrator (Server Settings > Mappings) :
      /component_root = {ABSOLUTE_PATH_OF_CF2023}/dev1_repository/wwwroot/component/

      Dev2_Repository Administrator (Server Settings > Mappings) :
      /component_root = {ABSOLUTE_PATH_OF_CF2023}/dev2_repository/wwwroot/component/

    B
    bell_the_catAuthor
    Inspiring
    February 26, 2025

    @BKBK Your assumptions are correct.  Each instance CF Admin console is accessed on a different port.  The CF Admin page shows the different instance Server name in the corner after login.

     

    • Check the contents of /Prime/bin/jvm.config, /Dev1/bin/jvm.config and /Dev2/bin/jvm.config. Ensure that none of them contains an unexpected setting or refers to an incorrect path;

     

    Nothing in jvm.config references anything in the source code path.  Most paths reference {application.home}

     

    • Check the settings Server Settings > Mappings in the Administrators of Prime, Dev1 and Dev2. Ensure that, in each case, the paths pertain to the relevant instance. 

     

    Yes, the mapping in each instance points to the source path for that specific instance.  

     

    I'm going back through the instance config/app isolation to make sure I didn't miss anything, but nothing so far.  Any other suggestions will be appreciated.  Thanks!

    BKBK
    Community Expert
    BKBKCommunity Expert
    Community Expert
    February 26, 2025

    There was an oversight in my last post, which I have now updated. 

    Please read:

     

    Where necessary, edit the instance settings, respectively, to

     

    Prime Administrator (Server Settings > Mappings) :
    /component_root ={ABSOLUTE_PATH_OF_CF2023}/prime/wwwroot/component/


    Dev1_Repository     Administrator (Server Settings > Mappings) :
    /component_root = {ABSOLUTE_PATH_OF_CF2023}/dev1_repository/wwwroot/component/

     

    Dev2_Repository Administrator (Server Settings > Mappings) :
    /component_root = {ABSOLUTE_PATH_OF_CF2023}/dev2_repository/wwwroot/component/

     

    In addition, everything I say with regard to the Administrator does apply to Application.cfc. So search the code base of Dev1_Repository and Dev2_Repository for occurrence of the word "prime" within mappings. 

    Charlie Arehart
    Community Expert
    Charlie ArehartCommunity Expert
    Community Expert
    February 26, 2025

    Can you clarify:

    • Do you really mean this is one machine--running one install of cf2023, under which you've created these multiple instances?
    • And as for the "Server Settings for that instance", do you mean the mappings page in the cf admin for each instance?

    If yes to both of the above, then absolutely I agree that such a mapping defined in one instance should not be seen or used by any other.

     

    If you feel that somehow the code Is finding another mapping, it is of course possible to set application-level mappings. And I realize you'll think that can't be the issue because of the separate directories. But you should at least check for it.

     

    And the easy way to do that is to run the function get applicationmetadata (), which returns a struct with many keys representing the many settings that can be set at the app level or are inherited from the sever level. (I have to admit I've not checked if it specifically lists admin mappings, but it may.)

     

    Let us know what you find, or at least your answers to the first questions. Thx. 

    /Charlie (troubleshooter, carehart. org)
    B
    bell_the_catAuthor
    Inspiring
    February 26, 2025
    • Do you really mean this is one machine--running one install of cf2023, under which you've created these multiple instances?

     

    Yes, one installation of CF 2023 on a Linux server.  I've created multiple instances following the guidelines from Adobe here  https://helpx.adobe.com/coldfusion/configuring-administering/using-multiple-server-instances.html#UsingMultipleServerInstances-Webserverconfigurationforapplicationisolation  We use different URLs for each instance and Apache web server configured for multihoming.

     

    • And as for the "Server Settings for that instance", do you mean the mappings page in the cf admin for each instance?

     

    Yes, each server instance has it's own CF Admin site, and I've configured the Server Settings> Mappings page on each instance's CF Admin site to point to the instance-specific source code repository on the filesystem.  The logical name for the mapping is the same across all instances, but the target location is different.  The intent is to be able to use the same source code on each instance.

     

    The code throwing the error does the following.  We have a page /dev1/sub/folders/CallingFile.cfm which creates a component as follows:

    <cfset variables.SomeComponentCFC = CreateObject("component", "component_root.SomeComponent") />

    Note that all components live in /dev1/component/.

     

    SomeComponentCFC now tries to create another component as follows:

    <cfset variables.OtherComponentCFC = CreateObject("component", "component_root.OtherComponent") />

     

    This throws an error.  Looking at the stack trace first:

     

    The error occurred in /prime/component/SomeComponent.cfc: line XX

    Called from /dev1/sub/folders/CallingFile.cfm: line XX

    This is where I question what's happening, because the stack trace makes it appear that the original component was created (successfully) by referencing the source on Prime, not Dev1.  Then the attempt to create another component from the (Prime) component is denied.

     

    Security: The requested template has been denied access to /dev1/sub/folders/component_root/OtherComponent.cfc.

    The following is the internal exception message: access denied ("java.io.FilePermission" "/dev1/sub/folders/component_root/OtherComponent.cfc" "read")

    A couple things of note here.  First off we have the apparently successfully created Prime component denied access to create a component from Dev1 path, which I supposed is correct because of the sandboxes, although how the first component was created in Prime sandbox, I don't know.

     

    Secondly, the above path noted in the error doesn't exist.  The actual component lives at /dev1/component/OtherComponent.cfc which reflects the instance mapping of component_root = /dev1/component.  So the mapping isn't being recognized, the logical name is being assumed to be the physical folder, which I suppose is secondary to the point of why is the original component apparently being created from the Prime source tree???

    B
    bell_the_catAuthor
    Inspiring
    February 26, 2025

    An update to the above.  If I add a leading slash to the mapping in CreateObject, the error goes away, but debug info for the page still shows that all the components are being created out of Prime source tree not Dev1 source tree.

    Terms & ConditionsAccessibility statement
    Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices