ColdFusion call to webservice gives org.xml.sax.SAXException

Question

We are a small team with one ASP.NET web developer and one ColdFusion developer. Neither of us knows the other's environment. I wrote an ASMX webservice using Visual Studio 2005 and a web application project in Visual Studio 2008 that successfully consumes the web service. But now we are trying to have my ColdFusion colleague consume the webservice and we are getting results we cannot interpret (except to surmise that the target webservice is not even being reached but that some "system layer" used by ColdFusion is failing.

EDIT - update: 02 June 2009:

Top most part of the error message seen by CF developer:

"Could not generate stub objects for web service invocation"

Here is the stack trace seen by the CF client:

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)

Here is the signature of the webmethod we are attempting to call:

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

We are quite confused about how to proceed. Tomorrow I could post the CF source code if that would be useful but from what I've seen it is very straightforward and most of the arguments in the CF invoke of the service are constants (strings) at this point in our unit testing.

Any help or suggestions of appropriate CF forums would be appreciated. Thanks.

EDIT-update 02 June 2009:

Here is the CFML code:

<!--- 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>

Please note we have simplified this considerably trying to get things working. Arguments 1 and 4 above are simply string constants. Argument 2 is our attempt at the byte array expected by .Net. We believe we are NOT being rejected by the .Net web service; rather, it appears from the stack trace that it is falling into the SAX exception before the message is even being sent across the network. The .Net webservice does NOT log anything to the application log or system log of the server on which it runs.

The ColdFusion release is: ColdFusion MX 7.

EDIT - 04 June 2009:

Fix for this problem emerged through another more-specialized forum:

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

In short, CF MX 7 fails miserably (error msg gives no clue) when the target webservice is configured in IIS with "Integrated Windows Authentication" (our's is like that and needs to be). More research led to this:

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

We are still chasing this and trying to get a totally workable solution. The bottom line is that the ColdFusion "administrator" must do some "special configuring" to get the "generated Java stubs" able to connect to a .Net webservice that requires Windows authentication.

Answer 1

The CFML would be handy. Also, what version of CF are you using? I know earlier versions of CF had issues if there were any overloaded methods in your web service. I am unaware if this is an issue in the latest version or not.

Answer 2

The element type "META" must be terminated by the matching end-tag "</META>".

That error message leads me to suspect that ColdFusion is attempting to use an XML parser to parse an HTML document. If I had to guess, I'd say it's probably trying to parse the ASP.NET "yellow screen of death". I suspect a malformed request from CF is causing an error on the .NET side, and you need to check your error logs on the .NET side to get a clue as to what specifically is being objected to.

Edit: By "yellow screen of death" I was just referring to the standard ASP.NET error page, which shows the error message and a stack trace on a yellow background.

In response to your updates, I can think of a few possibilities to check:

1. The stack trace and the second error message you posted seems to indicate that the problem is occurring while CF is downloading and parsing the WSDL to create proxy objects, long before actually calling your method. If you paste "http://trim/trimbroker/fileservice.asmx?wsdl" into a web browser, do you get WSDL or HTML? Perhaps you get redirected to a login page or something? If you don't get the WSDL XML document in your browser, CF isn't going to be able to get it either.

2. Your CF code is passing a base-64 string into a parameter that expects a byte array. Is the CF webservice stack smart enough to translate base-64 strings to byte arrays? I would be surprised, but maybe. Can you create byte arrays in CF? You couldn't last time I used CF, but that was a long time ago. You could try passing objBinaryData directly into the incomingArray parameter without converting to base-64, but if that doesn't work it might be easiest to change the type of incomingArray on the .NET side to string, and call Convert.FromBase64String() inside the method.

Answer 3

I got the same problem, turned out because CF service is running under Local System, didn't have access to the wsdl, so ASP.Net return unauthorize access.

Try use cfhttp to get the wsdl and see what the cfhttp.fileContent is, you might have the same problem.