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

Я использую 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 пытается отобразить сложный объект на панели отладчика и терпит неудачу.

Единственное, что я нашел в Интернете, это this thread в группе transfer-dev Google ... кто-то, кто видел кучу похожих ошибок и подумал, может быть, это ошибка CF9. Единственный ответ, предлагавший какое-либо решение, был this, предлагая исправление, которое, похоже, зависит от передачи.

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

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

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

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


coldfusion coldfusion-9 coldbox
person Dave DuPlantis    schedule 18.04.2011    source источник
comment
Дэйв, если это все еще проблема, возможно, вам повезет, разместив сообщение в группе Google ColdBox: groups.google.com/forum/#!forum/coldbox   -  person Aaron Greenlee    schedule 06.08.2011
comment
Спасибо, Аарон. Да, это все еще происходит; есть еще одна проблема, которую я иногда замечал, но только в моем локальном экземпляре, а также только при включенном режиме отладки, так что это может быть связано с этим. Я посмотрю, смогу ли я собрать более конкретную информацию и опубликовать в группе то, что найду.   -  person Dave DuPlantis    schedule 07.08.2011

Ответы (1)


arrow_upward
0
arrow_downward

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

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

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

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

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

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

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

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

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

person Mike Causer    schedule 22.11.2011
comment
Я считаю, что значения по умолчанию: доверенный кеш - ложь, шаблон кеша в запросе - истина, кеш компонентов - истина, файлы классов сохранения - истина, пути кэширования веб-серверов - ложь. - person Dave DuPlantis; 07.03.2012