1

ローカル マシンで CF 9.0.1 Developer と Coldbox 3.0.0 を実行しています (Apache で 32 ビット CF9 を実行している 64 ビット Windows Vista)。SVN からチェックアウトしてローカルにデプロイしたアプリケーションに取り組んでいます。すべてが正しく機能しているように見えますが、アプリケーション ログは次のようなエントリでいっぱいです。

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

exception.log には、例外ごとに非常に長いスタック トレースがあり、おそらく 150 行程度です。これは次のように始まります。

"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)

これは本番環境で実行されているアプリのバージョンです。これが私のローカル バージョンにあると思わせるのは、スタック トレースに次のように表示されることです。

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 がデバッガー パネルに複雑なオブジェクトを表示しようとして失敗したようです。

これまでにオンラインで見つけたのは、Google の transfer-dev グループのこのスレッドだけでした...似たようなエラーをたくさん見て、おそらく CF9 のバグだと思った人がいます。あらゆる種類の解決策に関する唯一の返信はthis oneであり、転送固有の修正を示唆しています。

これらのエラーの原因を知っている人はいますか? それらを修正することは、本番アプリの場合ほど重要ではありませんが、これらのエラーでログをスパムしていると、正当なエラーが発生したときにそれを見つけるのが難しくなります.

更新: CollectionPanel.cfm テンプレートを使用して根本的な原因を特定してきましたが、ここで一貫して例外がスローされます。

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

を try-catch でラップしようとしましcfdumpたが、常に同じコード行から例外がスローされます。これらのエラーが発生したページに目に見える影響を与えないことを考えると、これは理にかなっていると思います。

4

1 に答える 1

0

呼び出しでは<cfdump>なく、が原因ではないようです。GetMetaData()具体的には、cfc のメタ データを取得するときに、現在のファイルがコンパイルされた後 (および GetMetaData が実行された場所) に変更された別の cfc を拡張し、GetMetaData() 戻り値の extends 構造体を更新する必要があります。Cf は、おそらくパフォーマンス上の理由から、メタ データ構造体を 1 回だけ生成します。

私はそれがcfのバグかもしれないと思う...

TemplateProxyFactory.getTemplateFileHelper() 内runtime.resolveTemplatePath(compName + ".cfc")で、compName がどこにあるかを呼び出していますname.replace('.', '/')

マッピングを使用するまでは問題ありません。ドットをスラッシュに直接置き換える場合は、TemplateProxy.getMetaData() の場合と同様に、先頭にスラッシュを追加する必要があります。

先頭のスラッシュがない場合、resolveTemplatePath() は null を返します。これにより、VFSFileFactory.getFileObject() 呼び出しがトリガーされ、親 cfc 名から File オブジェクトを取得しようとします。

VFSFileFactory に到達する前に、pageContext で Util.getBaseTemplatePath() を呼び出します。内部では、pageContext から ServletContext を取得し、実際のパスを取得できるように getServletPath() を呼び出そうとします。Utils.getServletPath() は属性 "javax.servlet.include.servlet_path" を取得しようとしますが、これは私のマシン (そしておそらくあなたのマシン) には存在せず、null を返します。

これを呼び出して確認できます: isNull(getPageContext().getRequest().getRequest().getAttribute("javax.servlet.include.servlet_path"));- はい、2 つの .getRequest() 呼び出しがあるはずです。

そのため、Cf は、拡張ファイルが変更されたときに cfc getMetaData() 呼び出しで拡張構造体を更新しようとしているようで、最初に構造体を生成したときとは異なる方法でそれを行います。

管理者の cf で、[サーバー設定] > [キャッシュ] の下の設定は何ですか? 信頼できるキャッシュ? リクエストでテンプレートをキャッシュしますか? コンポーネントキャッシュ? クラスファイルを保存しますか? Web サーバーのパスをキャッシュしますか?

于 2011-11-22T05:38:46.123 に答える