本地主机上的ColdFusion 9和ColdBox中的NullPointerException

问题描述

我在本地计算机（在Apache上运行32位CF9的64位Windows Vista）上运行CF 9.0.1 Developer和Coldbox 3.0.0。我正在使用已从SVN检出并在本地部署的应用程序。一切似乎都正常运行，但是我的应用程序日志中充满了这样的条目：

I'm running CF 9.0.1 Developer and Coldbox 3.0.0 on my local machine (64-bit Windows Vista running 32-bit CF9 on Apache). I'm working on an application that I've checked out from SVN and deployed locally. Everything seems to be working correctly, but my application log is filling up with entries like this:

Apr 18, 2011    12:41 PM    Error       jrpp-7

exception.log对每个异常的堆栈跟踪都非常长，可能有150行或者。开头是这样：

exception.log has an extremely long stack trace for each exception, maybe 150 lines or so. It starts with this:

"Error","jrpp-4","04/18/11","11:07:30",,""
java.lang.NullPointerException
    at coldfusion.util.Utils.getServletPath(Utils.java:86)
    at coldfusion.util.Utils.getServletPath(Utils.java:76)
    at coldfusion.util.Utils.getBaseTemplatePath(Utils.java:405)
    at coldfusion.runtime.TemplateProxyFactory.getTemplateFileHelper
        (TemplateProxyFactory.java:1522)
    at coldfusion.runtime.MetadataUtils.getComponentMetadata
        (MetadataUtils.java:112)
    at coldfusion.runtime.CfJspPage.GetComponentMetaData(CfJspPage.java:2667)
    at coldfusion.runtime.TemplateProxy.getRuntimeComponentMetadata
        (TemplateProxy.java:1756)
    at coldfusion.runtime.TemplateProxy.getRuntimeMetadata
        (TemplateProxy.java:1617)
    at coldfusion.runtime.MetadataUtils.getMetaData(MetadataUtils.java:54)
    at coldfusion.runtime.CfJspPage.GetMetaData(CfJspPage.java:2640)
    at cfEventHandler2ecfc862260423$funcPOSTLOAD.runFunction
        (C:\ColdFusion9\wwwroot\ybocv5\coldbox\system\orm\hibernate
            \EventHandler.cfc:30)

这是已在生产环境中运行的应用程序的一个版本，在我的本地版本上只是它在堆栈跟踪中的外观：

This is a version of an app that has been running in production, and what makes me think this is just on my local version is the appearance of this in the stack trace:

at cfdump2ecfm471394032$funcRENDEROUTPUT.runFunction
    (E:\cf9_updates_rc\cfusion\wwwroot\WEB-INF\cftags\dump.cfm:704)
...
at cfCollectionPanel2ecfm961210602.runPage
    (C:\ColdFusion9\wwwroot\ybocv5\coldbox\system\includes
        \panels\CollectionPanel.cfm:40)

我们在生产中不使用cfdump；看来ColdBox试图在调试器面板中显示复杂的对象而失败。

We don't use cfdump in production; this looks like ColdBox is trying to display a complex object in a debugger panel and failing.

到目前为止，我在网上唯一发现的是在Google的transfer-dev小组...有人看到很多类似的错误，并认为这可能是CF9错误。使用任何解决方案的唯一答复是，表明此修复似乎特定于传输。

The only thing I found online so far was this thread in Google's transfer-dev group ... someone who saw a bunch of similar errors and thought maybe it was a CF9 bug. The only reply with any sort of solution was this one, suggesting a fix that seems to be Transfer-specific.

有人知道什么可能导致这些错误吗？对我来说，修复它们并不像在生产应用程序上那样重要，但是，如果我用这些错误向日志发送垃圾邮件，那么当它们发生时很难找到合法的错误。

Does anyone know what might be causing these errors? It's not as important to me to fix them as it would be on a production app, but if I'm spamming my logs with these errors, it's hard to find legitimate errors when they do occur.

更新：：我一直在使用CollectionPanel.cfm模板来确定根本原因，并且始终在这里抛出异常：

Update: I've been working with the CollectionPanel.cfm template to identify the root cause, and the exception is consistently thrown here:

    <cfelseif isObject(varVal)>
        <!--- this cfdump is the guilty party ... --->
        <cfdump var="#varVal#" expand="false" top="2">
    <cfelse>

我尝试将 cfdump 包装在一个try-catch，但是总是从同一行代码中抛出异常。我想这是有道理的，因为这些错误对其发生的页面没有任何可见的影响。

I've tried wrapping the cfdump in a try-catch, but the exception is thrown anyway, always from that same line of code. This makes sense, I guess, given that these errors don't have any visible effect on the pages on which they occur.

推荐答案

它似乎不是由< cfdump> 引起的，而是由 GetMetaData（）调用引起的。
特别是当您获得一个cfc的元数据时，该元数据扩展了另一个cfc，该cfc在当前编译后（以及运行GetMetaData的地方）已被修改，它需要在GetMetaData（）中更新扩展结构返回。 Cf只生成一次元数据结构，很可能是出于性能原因。

It appears to not be caused from a <cfdump> instead from a GetMetaData() call.Specifically when you get the meta data of a cfc, which extends another cfc which has been modified after the current has been compiled (and where GetMetaData has been run) where it needs to update the extends struct in the GetMetaData() return. Cf only generates the meta data struct once, most likely for performance reasons.

我认为这可能是cf ...中的错误...

I think it might be a bug in cf...

在TemplateProxyFactory.getTemplateFileHelper（）内部，它正在调用 runtime.resolveTemplatePath（compName + .cfc），其中compName是 name .replace（'。'，'/'）

Inside the TemplateProxyFactory.getTemplateFileHelper() it's calling runtime.resolveTemplatePath(compName + ".cfc") where compName is name.replace('.', '/')

一切都很好，直到您使用映射为止。如果您直接用斜杠替换点，则需要添加一个前导斜杠，就像它们在TemplateProxy.getMetaData（）

All good and well until you use a mapping. If you straight out replace dots with slashes, you'll need to add a leading slash, just like they do in TemplateProxy.getMetaData()

如果没有前导斜杠，resolveTemplatePath （）返回null，这会触发VFSFileFactory.getFileObject（）调用，该调用尝试从父cfc名称获取File对象。

Without the leading slash, resolveTemplatePath() returns null, which triggers the VFSFileFactory.getFileObject() call which tries to get a File object from the parent cfc name.

在到达VFSFileFactory之前，它使用pageContext调用Util.getBaseTemplatePath（）。在其内部，从pageContext获取ServletContext并尝试调用getServletPath（）以便获取其真实路径。 Utils.getServletPath（）尝试获取属性 javax.servlet.include.servlet_path，该属性在我的机器（可能是您的机器）上不存在，并返回null。

Before it even gets to the VFSFileFactory, it calls Util.getBaseTemplatePath() with the pageContext. Inside it gets the ServletContext from the pageContext and tries to call getServletPath() so that it can get its real path. Utils.getServletPath() tries to get the attribute "javax.servlet.include.servlet_path" which on my machine (and probably yours) doesn't exist and returns null.

您可以通过以下方式进行检查： isNull（getPageContext（）。getRequest（）。getRequest（）。getAttribute（ javax.servlet.include.servlet_path））; -是的，应该在那里有两个.getRequest（）调用。

You can check by calling this: isNull(getPageContext().getRequest().getRequest().getAttribute("javax.servlet.include.servlet_path")); - yes, there is supposed to be two .getRequest() calls in there.

因此，似乎Cf正在尝试刷新它在cfc getMetaData（）调用中的扩展结构

So it seems Cf is trying to refresh it's extends struct in a cfc getMetaData() call when the extended file is modified and does it a different way then when it first generated the struct.

在您的cf admin中，服务器设置>缓存下的设置是什么？
受信任的缓存？请求中有缓存模板？组件缓存？保存课程文件吗？缓存Web服务器路径？

In you cf admin, what are you settings under Server Settings > Caching?Trusted cache? Cache template in request? Component cache? Save class files? Cache web server paths?

这篇关于本地主机上的ColdFusion 9和ColdBox中的NullPointerException的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！