我有一个多层目录结构的CF9项目。 在根级别，我拥有带有Application.cfc的实时生产站点。 它包含许多绑定到'debugMode'标志的变量 - 所以在生产站点的情况下，该标志设置为false。
在生产站点的一个子目录中，我有一个包含该站点测试版本的文件夹。 这有其自己的Application.cfc，其debugMode设置为true。 除了我们正在测试的这个标志和更改外，它与生产Application.cfc相同。
直到我们添加了用于重置Application.cfc的逻辑以便在不等待超时（我们已经设置为30分钟）的情况下查看我们的更改时，没有任何问题。
为了达到这个目的，我们将这个模块添加到了Application.cfc中的'OnRequestStart'函数中（它在生产版本和测试版本中都存在）：
<cfif StructKeyExists( URL, "reset" )> <!--- Reset application and session. ---> <cfset THIS.OnApplicationStart() /> <cfset THIS.OnSessionStart() /> </cfif>这最初似乎工作正常。 如果我们在测试版本的任何页面的url上添加'？reset'，则对Application.cfc所作的更改立即反映出来，但我们很快发现了一个令人讨厌的副作用：在测试版本上调用重置ALSO更改我们的生产站点以使用测试Application.cfc的版本，从而大大放大了一切。
在生产站点上运行'？reset'逻辑解决了这个问题，但是导致所有的测试页面都使用生产Application.cfc而不是测试版本。 等待Application.cfcs超时并自动刷新没有任何区别，所以现在我们的测试环境已经搞乱了。
任何有关正在进行或要做什么的见解都将非常感谢，因为我们相当难过。 这仅仅是一个糟糕的建筑？ 我们继承了它，现在已经习惯了这种结构，所以快速修复将是首选，但我愿意接受建议。
谢谢。
I have a CF9 project set up with a multi-tiered directory structure. At the root level I have the live production site with its Application.cfc. It contains a number of variables that are bound to a 'debugMode' flag--so in the case of the production site, this flag is set to false.
In a subdirectory of the production site, I have a folder containing a testing version of the site. This has its own Application.cfc with debugMode set to true. Other than this flag and changes that we are testing, it's identical to the production Application.cfc.
There haven't been any problems with this UNTIL we added logic for resetting Application.cfc in order to see our changes without waiting for the timeout (which we have set to 30 minutes).
To accomplish this, we added this block to the 'OnRequestStart' function in Application.cfc (it is present on both production and testing versions):
<cfif StructKeyExists( URL, "reset" )> <!--- Reset application and session. ---> <cfset THIS.OnApplicationStart() /> <cfset THIS.OnSessionStart() /> </cfif>This initially appeared to work fine. If we add '?reset' to the url for any page on the testing version, changes made Application.cfc are reflected immediately, but we quickly discovered a nasty side effect: calling reset on the testing version ALSO changes our production site to use the testing version of Application.cfc, thereby mightily fubaring everything.
Running the '?reset' logic on the production site fixed this problem, but then caused all the testing pages to use the production Application.cfc instead of the testing version. Waiting for the Application.cfcs to time out and refresh automatically made no difference, so now our test environment is messed up.
Any insight into what's going on or what to do would be greatly appreciated as we are fairly stumped. Is this simply a poor architecture? We inherited it and are now quite accustomed to this structure, so so a quick fix would be preferred, but I'm open to suggestions.
Thanks.
最满意答案
问题很可能是两个application.cfc文件指定了相同的应用程序名称。
因此，它们本质上是相同的应用程序。
因此，无论您是从“Test”站点还是“Live”站点触发刷新，它都会重置相同的应用程序，然后重新实例化您发出重置的任何版本的变量。
您需要将“测试”应用程序的应用程序名称设置为与实时应用程序不同的内容。
对于测试：
<!--- For the "Test" Application ---> <cfset this.name = "TESTApplication">为了生活：
<!--- For the "Live" Application ---> <cfset this.name = "Application">The issue is most likely that the two application.cfc files specify the same application name.
So, they are, in essence, the same application.
So, whether you trigger the refresh from the "Test" site or the "Live" site, its resetting the same application, then re-instantiating the variables from whatever version you issued the reset from.
You need to set the application name for the "Test" application to something different then the live application.
For Test:
<!--- For the "Test" Application ---> <cfset this.name = "TESTApplication">For Live:
<!--- For the "Live" Application ---> <cfset this.name = "Application">更多推荐
发布评论