Вызов ColdFusion к веб-сервису дает исключение org.xml.sax.SAXException - PullRequest
1 голос
/ 02 июня 2009

Мы небольшая команда с одним веб-разработчиком ASP.NET и одним разработчиком ColdFusion. Никто из нас не знает окружение другого. Я написал веб-сервис ASMX с использованием Visual Studio 2005 и проекта веб-приложения в Visual Studio 2008, который успешно использует веб-сервис. Но теперь мы пытаемся заставить моего коллегу из ColdFusion использовать веб-сервис, и мы получаем результаты, которые мы не можем интерпретировать (за исключением предположения, что целевой веб-сервис даже не достигается, но что некоторый «системный уровень», используемый ColdFusion, не работает.

РЕДАКТИРОВАТЬ - обновление: 02 июня 2009 г .:

Верхняя часть сообщения об ошибке, видимого разработчиком CF:

"Could not generate stub objects for web service invocation"

Вот трассировка стека, видимая клиентом CF:

org.xml.sax.SAXException: Fatal Error: URI=null Line=11: The element type "META" must be terminated by the matching end-tag "</META>".
    at org.apache.axis.utils.XMLUtils$ParserErrorHandler.fatalError(XMLUtils.java:723)
    at org.apache.xerces.util.ErrorHandlerWrapper.fatalError(Unknown Source)
    at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source)
    at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source)
    at org.apache.xerces.impl.XMLScanner.reportFatalError(Unknown Source)
    at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanEndElement(Unknown Source)
    at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source)
    at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
    at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
    at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
    at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
    at org.apache.xerces.parsers.DOMParser.parse(Unknown Source)
    at org.apache.xerces.jaxp.DocumentBuilderImpl.parse(Unknown Source)
    at org.apache.axis.utils.XMLUtils.newDocument(XMLUtils.java:369)
    at org.apache.axis.utils.XMLUtils.newDocument(XMLUtils.java:388)
    at coldfusion.xml.rpc.XmlRpcServiceImpl.retrieveWSDL(XmlRpcServiceImpl.java:647)
    at coldfusion.xml.rpc.XmlRpcServiceImpl.access$000(XmlRpcServiceImpl.java:51)
    at coldfusion.xml.rpc.XmlRpcServiceImpl$1.run(XmlRpcServiceImpl.java:208)
    at java.security.AccessController.doPrivileged(Native Method)
    at coldfusion.xml.rpc.XmlRpcServiceImpl.registerWebService(XmlRpcServiceImpl.java:201)
    at coldfusion.xml.rpc.XmlRpcServiceImpl.getWebService(XmlRpcServiceImpl.java:475)
    at coldfusion.xml.rpc.XmlRpcServiceImpl.getWebServiceProxy(XmlRpcServiceImpl.java:430)
    at coldfusion.tagext.lang.InvokeTag.doEndTag(InvokeTag.java:381)
    at cfuploadfileSimple2ecfm1056043715.runPage(D:\AMTSTEST\webservice\uploadfileSimple.cfm:68)
    at coldfusion.runtime.CfJspPage.invoke(CfJspPage.java:152)
    at coldfusion.tagext.lang.IncludeTag.doStartTag(IncludeTag.java:349)
    at coldfusion.filter.CfincludeFilter.invoke(CfincludeFilter.java:65)
    at coldfusion.filter.ApplicationFilter.invoke(ApplicationFilter.java:225)
    at coldfusion.filter.PathFilter.invoke(PathFilter.java:86)
    at coldfusion.filter.ExceptionFilter.invoke(ExceptionFilter.java:69)
    at coldfusion.filter.BrowserDebugFilter.invoke(BrowserDebugFilter.java:52)
    at coldfusion.filter.ClientScopePersistenceFilter.invoke(ClientScopePersistenceFilter.java:28)
    at coldfusion.filter.BrowserFilter.invoke(BrowserFilter.java:38)
    at coldfusion.filter.GlobalsFilter.invoke(GlobalsFilter.java:38)
    at coldfusion.filter.DatasourceFilter.invoke(DatasourceFilter.java:22)
    at coldfusion.filter.RequestThrottleFilter.invoke(RequestThrottleFilter.java:115)
    at coldfusion.CfmServlet.service(CfmServlet.java:107)
    at coldfusion.bootstrap.BootstrapServlet.service(BootstrapServlet.java:78)
    at jrun.servlet.ServletInvoker.invoke(ServletInvoker.java:91)
    at jrun.servlet.JRunInvokerChain.invokeNext(JRunInvokerChain.java:42)
    at jrun.servlet.JRunRequestDispatcher.invoke(JRunRequestDispatcher.java:257)
    at jrun.servlet.ServletEngineService.dispatch(ServletEngineService.java:541)
    at jrun.servlet.jrpp.JRunProxyService.invokeRunnable(JRunProxyService.java:204)
    at jrunx.scheduler.ThreadPool$DownstreamMetrics.invokeRunnable(ThreadPool.java:318)
    at jrunx.scheduler.ThreadPool$ThreadThrottle.invokeRunnable(ThreadPool.java:426)
    at jrunx.scheduler.ThreadPool$UpstreamMetrics.invokeRunnable(ThreadPool.java:264)
    at jrunx.scheduler.WorkerThread.run(WorkerThread.java:66)

Вот подпись веб-метода, который мы пытаемся вызвать:

[WebMethod]
    public string UploadFileBasic(string trimURL
        , byte[] incomingArray
        , string FileName
        , string TrimRecordTypeName)

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

Буду признателен за любую помощь или предложения соответствующих форумов CF. Благодарю.

РЕДАКТИРОВАНИЕ-обновление 02 июня 2009 г .:

Вот код CFML:

<!--- read test.txt file into a binary variable --->
<cffile action="readBinary"   file="#FileName#" variable="objBinaryData">
<!--- convert the binary variable to Base64 --->  
<cfset b64file = #toBase64(objBinaryData)#>
<!--- invoke .net web service --->
<cfinvoke webservice =  "http://trim/trimbroker/fileservice.asmx?wsdl" 
          method = "UploadFileBasic"      
          returnVariable = "recordNumber">
    <cfinvokeargument name="trimURL" value="trim/trimWSdev/trim.asmx" />
    <cfinvokeargument name="incomingArray" value="#b64file#" />
    <cfinvokeargument name="FileName" value="#form.FILENAME#" />
    <cfinvokeargument name="TrimRecordTypeName" value="Document" />
</cfinvoke>

Обратите внимание, что мы значительно упростили это, пытаясь заставить вещи работать. Аргументы 1 и 4 выше являются просто строковыми константами. Аргумент 2 - наша попытка получить массив байтов, ожидаемый .Net. Мы считаем, что веб-сервис .Net НЕ отвергает нас; скорее из трассировки стека видно, что он попадает в исключение SAX еще до отправки сообщения по сети. .Net webservice НЕ регистрирует ничего в журнале приложений или системном журнале сервера, на котором он работает.

Выпуск ColdFusion: ColdFusion MX 7.

РЕДАКТИРОВАТЬ - 04 июня 2009 г .:

Исправление этой проблемы появилось на другом более специализированном форуме:

http://forums.adobe.com/message/2009491#2009491

Короче говоря, CF MX 7 с треском проваливается (ошибка msg не дает подсказки), когда целевой веб-сервис настроен в IIS с «Интегрированной аутентификацией Windows» (наша система такая и должна быть). Дополнительные исследования привели к этому:

http://blog.tagworldwide.com/?p=16

Мы все еще преследуем это и пытаемся найти полностью работоспособное решение. Суть в том, что администратор ColdFusion должен выполнить «специальную настройку», чтобы «сгенерированные заглушки Java» могли подключаться к веб-сервису .Net, который требует аутентификации Windows.

Ответы [ 3 ]

3 голосов
/ 02 июня 2009

Тип элемента "META" должен быть завершается соответствующим конечным тегом "< / META >".

Это сообщение об ошибке заставляет меня подозревать, что ColdFusion пытается использовать синтаксический анализатор XML для анализа HTML-документа. Если бы мне пришлось угадывать, я бы сказал, что он, вероятно, пытается разобрать ASP.NET «желтый экран смерти». Я подозреваю, что неправильно сформированный запрос от CF вызывает ошибку на стороне .NET, и вам нужно проверить свои журналы ошибок на стороне .NET, чтобы получить представление о том, на что конкретно возражают.

Редактировать: Под "желтым экраном смерти" я просто ссылался на стандартную страницу ошибок ASP.NET, которая показывает сообщение об ошибке и след стека на желтом фоне.

В ответ на ваши обновления я могу подумать о нескольких возможностях проверки:

  1. Трассировка стека и второе опубликованное вами сообщение об ошибке, похоже, указывают на то, что проблема возникает, когда CF загружает и анализирует WSDL для создания прокси-объектов задолго до фактического вызова вашего метода. Если вы вставите "http://trim/trimbroker/fileservice.asmx?wsdl" в веб-браузер, получите ли вы WSDL или HTML? Возможно, вы будете перенаправлены на страницу входа или что-то еще? Если вы не получите XML-документ WSDL в своем браузере, CF isn ' Я тоже не смогу его получить.

  2. Ваш код CF передает строку base-64 в параметр, который ожидает байтовый массив. Является ли стек веб-службы CF достаточно умным для преобразования строк base-64 в байтовые массивы? Я был бы удивлен, но возможно. Можете ли вы создать байтовые массивы в CF? Вы не могли в прошлый раз, когда я использовал CF, но это было давно. Вы можете попробовать передать objBinaryData непосредственно в параметр входящего массива без преобразования в base-64, но если это не сработает, проще всего изменить тип входящего массива на стороне .NET на строку и вызвать Convert.FromBase64String () внутри метод.

0 голосов
/ 13 января 2010

У меня возникла та же проблема, потому что служба CF работает под локальной системой, не имела доступа к wsdl, поэтому ASP.Net возвращает неавторизованный доступ.

Попробуйте использовать cfhttp, чтобы получить wsdl и посмотреть, что такое cfhttp.fileContent, у вас может быть та же проблема.

0 голосов
/ 02 июня 2009

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

...