gpt4 book ai didi

coldfusion - 主站点子目录中的测试站点引用了错误的 Application.cfc

转载 作者:行者123 更新时间:2023-12-02 15:41:42 25 4
gpt4 key购买 nike

我有一个设置了多层目录结构的 CF9 项目。在根级别,我有带有 Application.cfc 的实时生产站点。它包含许多绑定(bind)到“debugMode”标志的变量——因此在生产站点的情况下,此标志设置为 false。

在生产站点的子目录中,我有一个包含站点测试版本的文件夹。它有自己的 Application.cfc,debugMode 设置为 true。除了这个标志和我们正在测试的更改之外,它与生产 Application.cfc 相同。

直到我们添加了重置 Application.cfc 的逻辑以便在不等待超时(我们已将其设置为 30 分钟)的情况下查看我们的更改之前,这一直没有任何问题。

为此,我们将此 block 添加到 Application.cfc 中的“OnRequestStart”函数(它存在于生产和测试版本中):

    <cfif StructKeyExists( URL, "reset" )>

<!--- Reset application and session. --->
<cfset THIS.OnApplicationStart() />
<cfset THIS.OnSessionStart() />

</cfif>

这最初似乎工作正常。如果我们在测试版本的任何页面的 url 中添加“?reset”,Application.cfc 所做的更改会立即反射(reflect)出来,但我们很快发现了一个令人讨厌的副作用:在测试版本上调用 reset 也会更改我们的生产站点以使用Application.cfc 的测试版本,从而极大地消除了一切。

在生产站点上运行“?reset”逻辑解决了这个问题,但随后导致所有测试页面使用生产 Application.cfc 而不是测试版本。等待 Application.cfcs 超时并自动刷新没有任何区别,所以现在我们的测试环境一团糟。

任何关于正在发生的事情或该做什么的见解都将不胜感激,因为我们相当困惑。这仅仅是一个糟糕的架构吗?我们继承了它,现在已经非常习惯这种结构,因此最好快速修复,但我愿意接受建议。

谢谢。

最佳答案

问题很可能是两个 application.cfc 文件指定了相同的应用程序名称。

因此,它们本质上是同一个应用程序。

因此,无论您是从“测试”站点还是“实时”站点触发刷新,它都会重置同一个应用程序,然后从您发布重置的任何版本重新实例化变量。

您需要将“测试”应用程序的应用程序名称设置为与实时应用程序不同的名称。

用于测试:

<!--- For the "Test" Application --->
<cfset this.name = "TESTApplication">

直播:

<!--- For the "Live" Application --->
<cfset this.name = "Application">

关于coldfusion - 主站点子目录中的测试站点引用了错误的 Application.cfc,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/3687464/

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com