重新加载 Fusebox 应用程序而不出现“未找到解析的文件或目录”的最佳方法是什么? 错误?

发布于 2024-07-17 13:14:01 字数 8126 浏览 5 评论 0原文

我有一个使用 CF8 和 Fusebox 5 的站点。每当我需要向站点添加新功能时,我通常都必须为控制器、模型或视图或全部添加新的保险丝到 Circuit.xml.cfm 中。 为了启用这些新功能/页面,我访问以下网址:

?fusebox.load=true&fusebox.parse=true&fusebox.password=password&fusebox.loadclean=true

最后一个参数是我最近发现的一个参数,并确定使用它可以启用我的新保险丝; 如果没有它,新的保险丝将无法被识别。 但是,当我这样做时,之前生成的所有解析文件都将被删除。 这不是什么大问题,因为它们是在第一次需要时动态重新生成的,但我有一些页面在访问时返回错误。 错误说找不到目录,但它们在那里,每次出现这个问题都是因为解析文件不存在。

这是堆栈跟踪的一个错误的示例:

Error - Parsed File or Directory not found.

Date/Time: Apr 25 2009 12:26:02

Type: fusebox.missingParsedFile

Message: Parsed File or Directory not found.

Detail:

Attempting to execute the parsed file 'login.logout.cfm' threw an error. This can occur if the parsed file does not exist in the parsed directory or if the parsed directory itself is missing.
Stack Trace:
    coldfusion.runtime.CustomException: Parsed File or Directory not found.
    at coldfusion.tagext.lang.ThrowTag.doStartTag(ThrowTag.java:124)
    at coldfusion.runtime.CfJspPage._emptyTag(CfJspPage.java:2644)
    at cffusebox52ecfm1214986498.runPage(C:\example.com\fb5core\fusebox5.cfm:216)
    at coldfusion.runtime.CfJspPage.invoke(CfJspPage.java:192)
    at coldfusion.tagext.lang.IncludeTag.doStartTag(IncludeTag.java:366)
    at coldfusion.runtime.CfJspPage._emptyTag(CfJspPage.java:2644)
    at cfindex2ecfm584653367.runPage(C:\example.com\index.cfm:3)
    at coldfusion.runtime.CfJspPage.invoke(CfJspPage.java:192)
    at coldfusion.tagext.lang.IncludeTag.doStartTag(IncludeTag.java:366)
    at coldfusion.runtime.CfJspPage._emptyTag(CfJspPage.java:2644)
    at cfApplication2ecfc1103573364$funcONREQUEST.runFunction(C:\example.com\Application.cfc:36)
    at coldfusion.runtime.UDFMethod.invoke(UDFMethod.java:418)
    at coldfusion.runtime.UDFMethod$ReturnTypeFilter.invoke(UDFMethod.java:360)
    at coldfusion.runtime.UDFMethod$ArgumentCollectionFilter.invoke(UDFMethod.java:324)
    at coldfusion.filter.FunctionAccessFilter.invoke(FunctionAccessFilter.java:56)
    at coldfusion.runtime.UDFMethod.runFilterChain(UDFMethod.java:277)
    at coldfusion.runtime.UDFMethod.invoke(UDFMethod.java:192)
    at coldfusion.runtime.TemplateProxy.invoke(TemplateProxy.java:448)
    at coldfusion.runtime.TemplateProxy.invoke(TemplateProxy.java:308)
    at coldfusion.runtime.AppEventInvoker.invoke(AppEventInvoker.java:74)
    at coldfusion.runtime.AppEventInvoker.onRequest(AppEventInvoker.java:243)
    at coldfusion.filter.ApplicationFilter.invoke(ApplicationFilter.java:269)
    at coldfusion.filter.RequestMonitorFilter.invoke(RequestMonitorFilter.java:48)
    at coldfusion.filter.MonitoringFilter.invoke(MonitoringFilter.java:40)
    at coldfusion.filter.PathFilter.invoke(PathFilter.java:86)
    at coldfusion.filter.ExceptionFilter.invoke(ExceptionFilter.java:70)
    at coldfusion.filter.ClientScopePersistenceFilter.invoke(ClientScopePersistenceFilter.java:28)
    at coldfusion.filter.BrowserFilter.invoke(BrowserFilter.java:38)
    at coldfusion.filter.NoCacheFilter.invoke(NoCacheFilter.java:46)
    at coldfusion.filter.GlobalsFilter.invoke(GlobalsFilter.java:38)
    at coldfusion.filter.DatasourceFilter.invoke(DatasourceFilter.java:22)
    at coldfusion.CfmServlet.service(CfmServlet.java:175)
    at coldfusion.bootstrap.BootstrapServlet.service(BootstrapServlet.java:89)
    at jrun.servlet.FilterChain.doFilter(FilterChain.java:86)
    at coldfusion.monitor.event.MonitoringServletFilter.doFilter(MonitoringServletFilter.java:42)
    at coldfusion.bootstrap.BootstrapFilter.doFilter(BootstrapFilter.java:46)
    at jrun.servlet.FilterChain.doFilter(FilterChain.java:94)
    at jrun.servlet.FilterChain.service(FilterChain.java:101)
    at jrun.servlet.ServletInvoker.invoke(ServletInvoker.java:106)
    at jrun.servlet.JRunInvokerChain.invokeNext(JRunInvokerChain.java:42)
    at jrun.servlet.JRunRequestDispatcher.invoke(JRunRequestDispatcher.java:284)
    at jrun.servlet.ServletEngineService.dispatch(ServletEngineService.java:543)
    at jrun.servlet.jrpp.JRunProxyService.invokeRunnable(JRunProxyService.java:203)
    at jrunx.scheduler.ThreadPool$DownstreamMetrics.invokeRunnable(ThreadPool.java:320)
    at jrunx.scheduler.ThreadPool$ThreadThrottle.invokeRunnable(ThreadPool.java:428)
    at jrunx.scheduler.ThreadPool$UpstreamMetrics.invokeRunnable(ThreadPool.java:266)
    at jrunx.scheduler.WorkerThread.run(WorkerThread.java:66)

我要解决此问题的方法是转到以下网址,该网址与前一个网址类似,但没有 fusionbox.loadclean=true:

?fusebox.password=password&fusebox.load=true&fusebox.parse=true

我尝试做的是转到第一个网址之后url,我会转到第二个,但错误仍然出现。

我正在寻找的是重新加载电路而不产生这些错误的正确方法。 我是第三个参与此站点的开发人员,因此前两个开发人员可能采用不同的方式来配置 Circuit.xml.cfm 的每个实例。 这些文件用于确定应用程序流程,包括所需内容、附加安全层以及指定某些属性。 这是 Fusebox 方法:

<!-- controller/circuit.xml.cfm -->
<circuit access="public">
    <fuseaction name="index">
        <set name="request.title" value="Account overview" />
        <do action="layout.header" />
        <do action="mdashboard.index" />
        <do action="vdashboard.index" />
        <do action="layout.footer" />
    </fuseaction>

    <fuseaction name="profile">
        <set name="request.title" value="Your Profile" />
        <do action="layout.header" />

        <!-- form submitted to the same page -->
        <if condition="isDefined('attributes.submit')">
            <true>
                <do action="mdashboard.updateprofile" />
                <do action="vdashboard.profile" />
            </true>
            <false>
                <do action="mdashboard.profile" />
                <do action="vdashboard.profile" />
            </false>
        </if>

        <do action="layout.footer" />
    </fuseaction>
</circuit>

<!-- model/circuit.xml.cfm -->
<circuit access="internal">
    <fuseaction name="index">
        <include template="sqlIndex" />
    </fuseaction>

    <fuseaction name="profile">
        <include template="sqlProfile" />
    </fuseaction>

    <fuseaction name="updateprofile">
        <include template="actUpdateProfile" />
    </fuseaction>
</circuit>

<!-- view/circuit.xml.cfm -->
<circuit access="internal">
    <fuseaction name="index">
        <include template="dspIndex" />
    </fuseaction>

    <fuseaction name="profile">
        <include template="dspProfile" />
    </fuseaction>
</circuit>

这是 Fusebox 和 ColdFusion 方法的混合:

<!-- controller/circuit.xml.cfm -->
<circuit access="public">
    <fuseaction name="index">
        <set name="request.title" value="Account overview" />
        <do action="layout.header" />
        <include template="ctrlIndex" />
        <do action="layout.footer" />
    </fuseaction>

    <fuseaction name="profile">
        <set name="request.title" value="Your Profile" />
        <do action="layout.header" />
        <include template="ctrlProfile" />
        <do action="layout.footer" />
    </fuseaction>
</circuit>

<!-- model/circuit.xml.cfm -->
<circuit access="internal">
</circuit>

<!-- view/circuit.xml.cfm -->
<circuit access="internal">
</circuit>

<!-- controller/ctrlProfile.cfm -->
<cfif isDefined("attributes.submit")>
    <cfinclude template="../model/actUpdateProfile.cfm">
</cfif>

<cfinclude template="../model/sqlPaymentOptions.cfm">
<cfinclude template="../view/dspPaymentOptions.cfm">

整个站点都采用这两种方法,我并不反对使用其中任何一种,但我的目标是减少用户尝试时可能出现的任何错误访问特定页面。 我在想,也许问题出在配置的混合方法上,我应该坚持只使用 Fusebox 方法,但我无法在这个错误中找到共同的趋势。 每次页面收到​​错误时,我们现有的错误处理程序都会向我发送电子邮件,因此我认为我可以自动调用我的第二个网址,并将它们重定向回发生此特定错误时生成错误的页面,但这有无限循环的可能性,并且它没有解决真正的问题。

我对这个问题的看法是错误的吗? 是否可以在 url 中包含一组属性,这些属性将强制站点识别新的熔丝而不清除我的解析文件? CF 本身并不难编码,但我对它还比较陌生,所以我可以倒着来讨论这个问题。 谢谢!

I have a site using CF8 and Fusebox 5. Anytime I need to add a new feature to the site, I usually have to add a new fuse to circuit.xml.cfm for either the controller, model, or view, or all. To enable these new features/pages, I go to the following url:

?fusebox.load=true&fusebox.parse=true&fusebox.password=password&fusebox.loadclean=true

The last parameter is one I recently picked up on and determined that using it would enable my new fuses; without it the new fuses are not recognized. However, when I do this, all of my parse files that were generated before are removed. This isn't much of a problem since they're regenerated on the fly when they are needed for the first time, but I have some pages that return errors when they are accessed. The error says directory not found, but they are there, each time this comes up it's because the parse file does not exist.

Here's an example of one error with the stack trace:

Error - Parsed File or Directory not found.

Date/Time: Apr 25 2009 12:26:02

Type: fusebox.missingParsedFile

Message: Parsed File or Directory not found.

Detail:

Attempting to execute the parsed file 'login.logout.cfm' threw an error. This can occur if the parsed file does not exist in the parsed directory or if the parsed directory itself is missing.
Stack Trace:
    coldfusion.runtime.CustomException: Parsed File or Directory not found.
    at coldfusion.tagext.lang.ThrowTag.doStartTag(ThrowTag.java:124)
    at coldfusion.runtime.CfJspPage._emptyTag(CfJspPage.java:2644)
    at cffusebox52ecfm1214986498.runPage(C:\example.com\fb5core\fusebox5.cfm:216)
    at coldfusion.runtime.CfJspPage.invoke(CfJspPage.java:192)
    at coldfusion.tagext.lang.IncludeTag.doStartTag(IncludeTag.java:366)
    at coldfusion.runtime.CfJspPage._emptyTag(CfJspPage.java:2644)
    at cfindex2ecfm584653367.runPage(C:\example.com\index.cfm:3)
    at coldfusion.runtime.CfJspPage.invoke(CfJspPage.java:192)
    at coldfusion.tagext.lang.IncludeTag.doStartTag(IncludeTag.java:366)
    at coldfusion.runtime.CfJspPage._emptyTag(CfJspPage.java:2644)
    at cfApplication2ecfc1103573364$funcONREQUEST.runFunction(C:\example.com\Application.cfc:36)
    at coldfusion.runtime.UDFMethod.invoke(UDFMethod.java:418)
    at coldfusion.runtime.UDFMethod$ReturnTypeFilter.invoke(UDFMethod.java:360)
    at coldfusion.runtime.UDFMethod$ArgumentCollectionFilter.invoke(UDFMethod.java:324)
    at coldfusion.filter.FunctionAccessFilter.invoke(FunctionAccessFilter.java:56)
    at coldfusion.runtime.UDFMethod.runFilterChain(UDFMethod.java:277)
    at coldfusion.runtime.UDFMethod.invoke(UDFMethod.java:192)
    at coldfusion.runtime.TemplateProxy.invoke(TemplateProxy.java:448)
    at coldfusion.runtime.TemplateProxy.invoke(TemplateProxy.java:308)
    at coldfusion.runtime.AppEventInvoker.invoke(AppEventInvoker.java:74)
    at coldfusion.runtime.AppEventInvoker.onRequest(AppEventInvoker.java:243)
    at coldfusion.filter.ApplicationFilter.invoke(ApplicationFilter.java:269)
    at coldfusion.filter.RequestMonitorFilter.invoke(RequestMonitorFilter.java:48)
    at coldfusion.filter.MonitoringFilter.invoke(MonitoringFilter.java:40)
    at coldfusion.filter.PathFilter.invoke(PathFilter.java:86)
    at coldfusion.filter.ExceptionFilter.invoke(ExceptionFilter.java:70)
    at coldfusion.filter.ClientScopePersistenceFilter.invoke(ClientScopePersistenceFilter.java:28)
    at coldfusion.filter.BrowserFilter.invoke(BrowserFilter.java:38)
    at coldfusion.filter.NoCacheFilter.invoke(NoCacheFilter.java:46)
    at coldfusion.filter.GlobalsFilter.invoke(GlobalsFilter.java:38)
    at coldfusion.filter.DatasourceFilter.invoke(DatasourceFilter.java:22)
    at coldfusion.CfmServlet.service(CfmServlet.java:175)
    at coldfusion.bootstrap.BootstrapServlet.service(BootstrapServlet.java:89)
    at jrun.servlet.FilterChain.doFilter(FilterChain.java:86)
    at coldfusion.monitor.event.MonitoringServletFilter.doFilter(MonitoringServletFilter.java:42)
    at coldfusion.bootstrap.BootstrapFilter.doFilter(BootstrapFilter.java:46)
    at jrun.servlet.FilterChain.doFilter(FilterChain.java:94)
    at jrun.servlet.FilterChain.service(FilterChain.java:101)
    at jrun.servlet.ServletInvoker.invoke(ServletInvoker.java:106)
    at jrun.servlet.JRunInvokerChain.invokeNext(JRunInvokerChain.java:42)
    at jrun.servlet.JRunRequestDispatcher.invoke(JRunRequestDispatcher.java:284)
    at jrun.servlet.ServletEngineService.dispatch(ServletEngineService.java:543)
    at jrun.servlet.jrpp.JRunProxyService.invokeRunnable(JRunProxyService.java:203)
    at jrunx.scheduler.ThreadPool$DownstreamMetrics.invokeRunnable(ThreadPool.java:320)
    at jrunx.scheduler.ThreadPool$ThreadThrottle.invokeRunnable(ThreadPool.java:428)
    at jrunx.scheduler.ThreadPool$UpstreamMetrics.invokeRunnable(ThreadPool.java:266)
    at jrunx.scheduler.WorkerThread.run(WorkerThread.java:66)

What I do to fix this problem is go to the following url, which is like the previous one, but without fusebox.loadclean=true:

?fusebox.password=password&fusebox.load=true&fusebox.parse=true

What I tried doing was after going to the first url, I would go to this second one, but the error still crops up.

What I'm looking for is the proper way to reload the circuits without generating these errors. I'm the third developer to get involved on this site, so the previous two may have had different styles of configuring each instance of circuit.xml.cfm. These files are used to determine the application flow of what includes are needed, additional security layers and specifying certain attributes. Here's the Fusebox method:

<!-- controller/circuit.xml.cfm -->
<circuit access="public">
    <fuseaction name="index">
        <set name="request.title" value="Account overview" />
        <do action="layout.header" />
        <do action="mdashboard.index" />
        <do action="vdashboard.index" />
        <do action="layout.footer" />
    </fuseaction>

    <fuseaction name="profile">
        <set name="request.title" value="Your Profile" />
        <do action="layout.header" />

        <!-- form submitted to the same page -->
        <if condition="isDefined('attributes.submit')">
            <true>
                <do action="mdashboard.updateprofile" />
                <do action="vdashboard.profile" />
            </true>
            <false>
                <do action="mdashboard.profile" />
                <do action="vdashboard.profile" />
            </false>
        </if>

        <do action="layout.footer" />
    </fuseaction>
</circuit>

<!-- model/circuit.xml.cfm -->
<circuit access="internal">
    <fuseaction name="index">
        <include template="sqlIndex" />
    </fuseaction>

    <fuseaction name="profile">
        <include template="sqlProfile" />
    </fuseaction>

    <fuseaction name="updateprofile">
        <include template="actUpdateProfile" />
    </fuseaction>
</circuit>

<!-- view/circuit.xml.cfm -->
<circuit access="internal">
    <fuseaction name="index">
        <include template="dspIndex" />
    </fuseaction>

    <fuseaction name="profile">
        <include template="dspProfile" />
    </fuseaction>
</circuit>

Here's the mixture of Fusebox and ColdFusion method:

<!-- controller/circuit.xml.cfm -->
<circuit access="public">
    <fuseaction name="index">
        <set name="request.title" value="Account overview" />
        <do action="layout.header" />
        <include template="ctrlIndex" />
        <do action="layout.footer" />
    </fuseaction>

    <fuseaction name="profile">
        <set name="request.title" value="Your Profile" />
        <do action="layout.header" />
        <include template="ctrlProfile" />
        <do action="layout.footer" />
    </fuseaction>
</circuit>

<!-- model/circuit.xml.cfm -->
<circuit access="internal">
</circuit>

<!-- view/circuit.xml.cfm -->
<circuit access="internal">
</circuit>

<!-- controller/ctrlProfile.cfm -->
<cfif isDefined("attributes.submit")>
    <cfinclude template="../model/actUpdateProfile.cfm">
</cfif>

<cfinclude template="../model/sqlPaymentOptions.cfm">
<cfinclude template="../view/dspPaymentOptions.cfm">

Both methods are employed throughout the site, and I'm not opposed to using either one, but my objective is to reduce any error that could come up when the user tries to access a particular page. I was thinking that maybe the problem is the mixed method of configurations, that I should stick with, say, the Fusebox method only, but I have not been able to find a common trend in this error. The error handler we have in place emails me each time a page receives an error, so I'm thinking that I could automatically call my 2nd url and redirect them back to the page that generated the error when this specific error occurs, but this has the potential for an infinite loop, and it doesn't address the real problem.

Am I going about this incorrectly? Is there set of attributes I can include in the url that will force the site to recognize new fuses without clearing my parse files? CF itself isn't difficult to code, but I'm still relatively new to it, so I could be going about this backwards. Thanks!

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

残花月 2024-07-24 13:14:01

注意:新的保险丝不需要保险丝盒重新加载 - 只有新的保险丝操作需要重新加载。

我不完全确定您遇到的错误是否如我所想,但无论如何,以下都是很好的做法...

当您进行更改并需要重新加载保险丝盒时,您会执行以下操作:应该做的是:

  1. 将最新代码部署到同一服务器上的预上线“暂存”区域。
    • 使用 fusebox.parseall=truefusebox.loadclean=true 在此区域生成已解析的文件
    • 将其中的所有文件复制到您的实时网络根目录中。
    • 在实时网站上执行保险丝盒fusebox.load=true - 没有其他内容(除了密码)。

(注意:如有必要,请在步骤 3 之前将站点设置为离线/维护模式,然后在步骤 4 之后再次将其重新上线)

NOTE: New fuses do not need a fusebox reload - only new fuseactions require one.

I'm not entirely certain if the errors you're getting are what I think they are, but the following is good practise regardless...

When you have made changes and need to reload fusebox, what you should do is this:

  1. Deploy the latest code to a pre-Live 'staging' area on the same server.
    • Generate your parsed files in this area using fusebox.parseall=true and fusebox.loadclean=true
    • Copy all files from there into your Live webroot.
    • Perform a fusebox fusebox.load=true on the Live site - nothing else (except password).

(Note: if necessary, before step 3 set your site to offline/maintenance mode, and then after step 4 put it back online again)

冬天的雪花 2024-07-24 13:14:01

有什么理由不使用fusebox.mode =“development-full-load”(在fusebox.xml中设置)? 如果您还没有在这种模式下进行开发,这可以让您的生活变得更轻松。

Is there any reason do not use fusebox.mode = "development-full-load" (set in fusebox.xml) ? This can make your live a bit easier, if you are not developing in this mode yet.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文