Исключения NullPointerException в ColdFusion 9 и ColdBox на локальном хосте - PullRequest
Новая
       21

Исключения NullPointerException в ColdFusion 9 и ColdBox на локальном хосте

1 голос
/ 18 апреля 2011

Я использую CF 9.0.1 Developer и Coldbox 3.0.0 на своем локальном компьютере (64-битная Windows Vista с 32-битным CF9 на Apache).Я работаю над приложением, которое я извлек из 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.Единственный ответ с любым видом решения был , этот , предлагая исправление, которое, похоже, относилось к передаче.

Кто-нибудь знает, что может быть причиной этих ошибок?Для меня не так важно их исправлять, как в производственном приложении, но если я рассылаю спам в своих журналах с этими ошибками, трудно найти допустимые ошибки, когда они возникают.

Обновление: Я работал с шаблоном CollectionPanel.cfm, чтобы определить основную причину, и здесь постоянно выдается исключение: 

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

Я пытался обернуть cfdump вtry-catch, но в любом случае выдается исключение, всегда из той же строки кода.Думаю, это имеет смысл, учитывая, что эти ошибки не оказывают видимого влияния на страницы, на которых они возникают.

1 Ответ

0 голосов
/ 22 ноября 2011

Кажется, это не вызвано <cfdump> вместо GetMetaData() вызова. В частности, когда вы получаете метаданные cfc, который расширяет другой cfc, который был изменен после компиляции текущего (и где GetMetaData был запущен), где он должен обновить структуру extends в возвращаемом GetMetaData (). Cf генерирует структуру метаданных только один раз, скорее всего из соображений производительности.

Я думаю, это может быть ошибка в cf ...

Внутри TemplateProxyFactory.getTemplateFileHelper () он вызывает runtime.resolveTemplatePath(compName + ".cfc"), где compName равно name.replace('.', '/')

Все хорошо, пока вы не используете отображение. Если вы заменяете точки косыми чертами, вам нужно добавить начальную косую черту, как это делают в TemplateProxy.getMetaData ()

Без косой черты resolTemplatePath () возвращает значение null, которое вызывает вызов VFSFileFactory.getFileObject (), который пытается получить объект File из родительского имени cfc.

Прежде чем он даже попадает в VFSFileFactory, он вызывает Util.getBaseTemplatePath () с pageContext. Внутри он получает ServletContext из pageContext и пытается вызвать getServletPath (), чтобы он мог получить свой реальный путь. Utils.getServletPath () пытается получить атрибут "javax.servlet.include.servlet_path", который на моей машине (и, вероятно, на вашей) не существует, и возвращает ноль.

Вы можете проверить, вызвав это: isNull(getPageContext().getRequest().getRequest().getAttribute("javax.servlet.include.servlet_path")); - да, там должно быть два вызова .getRequest ().

Так что, похоже, Cf пытается обновить свою структуру extends в вызове cfc getMetaData () при изменении расширенного файла и делает это иначе, чем при первом создании структуры.

Какие у вас настройки у администратора, в разделе «Настройки сервера»> «Кэширование»? Доверенный кеш? Шаблон кеша в запросе? Компонент кеша? Сохранить файлы классов? Кэшировать пути к веб-серверу?

...