Unable to read WSDL from URL

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

RLS - 09 May 2008 23:47 GMT

This is my first web service. I thought I read that the service registers
itself when first run, but it's just not jumping for me. I'd try registering
it, but I'm not sure how to fill in all the blanks in the CF Administrator's
Register Web Service form.

I believe I'm doing this pretty plain and simple. Any ideas why this won't
work? Tried both methods, both give the same error -- "Unable to read WSDL
from URL"

Calling URL: http://prod.trollsoftware.com/echotest.cfm
Is looking at: http://prod.trollsoftware.com/trollws.cfc?wsdl
which looks fine to me, but what do I know? This is my first....

RLS

Calling Code:
<h3>CFSCRIPT Method 2</h3>
<cfscript>

    ws=CreateObject("webservice","http://prod.trollsoftware.com/trollws.cfc?wsdl");
    wsresults=ws.echoString("Good day my dear fellows");
    writeoutput(wsresults);
</cfscript>

<h3>Invoke Method</h3>
<cfinvoke webservice="http://prod.trollsoftware.com/trollws.cfc?wsdl"
    method="echoString" input="Hello mates." returnvariable="foo" />

<h4>Results:</h4>
<CFOUTPUT>#foo#</CFOUTPUT>

The CFC I"m calling to create the WSDL:
<cfcomponent>
    <cffunction name="echoString" returntype="string" output="no" access="remote">
        <cfargument name="input" type="string">
        <cfreturn #arguments.input#>
    </cffunction>
</cfcomponent>

Reply to this Message

-==cfSearching==- - 10 May 2008 03:29 GMT

> Error: java.net.UnknownHostException: prod.trollsoftware.com.

The error message suggests there is a problem resolving the host name on your
end. I can view the WSDL from my browser, and successfully run your code from
my end. So the problem is not the CFC. Any chance something is blocking the
call or connection on your end?

Reply to this Message

RLS - 13 May 2008 16:22 GMT

Wow, that is off the wall. I sent the link to a fellow developer who is about
50 miles away from me, on a completely different ISP system, even, and he had
the same results that I encountered.

I don't suppose you'd have any idea what could possibly be blocking the call?
What to begin to look for? Seems pretty odd to me. I also had much the same
issue running some of the tests I found elsewhere. I don't suppose you (or
anyone monitoring this thread) have a "test" service that they know works that
I can try to run to see if it works for me or not?

I have tried this through both FireFox and IE 7, FYI.

RLS

Reply to this Message

RLS - 13 May 2008 16:42 GMT

P.S. Does this only work in CF8 ? I've copied this to a server using CF 7 just
to see if the URL was working against me, and I get even less far along - "HTTP
500 Internal Server Error" and trying to produce the WSDL gives me an AXIS
error, as such:

AXIS error
Sorry, something seems to have gone wrong... here are the details:

Fault - Error attempting to create Java skeleton for CFC web service; nested
exception is:
    coldfusion.xml.rpc.CFCInvocationException:
[coldfusion.xml.rpc.SkeletonClassLoader$UnresolvedCFCDataTypeException : Could
not resolve CFC datatype: /trollws.cfc]
AxisFault
faultCode: {http://schemas.xmlsoap.org/soap/envelope/}Server.generalException
faultSubcode:
faultString: Error attempting to create Java skeleton for CFC web service;
nested exception is:
    coldfusion.xml.rpc.CFCInvocationException:
[coldfusion.xml.rpc.SkeletonClassLoader$UnresolvedCFCDataTypeException : Could
not resolve CFC datatype: /trollws.cfc]
faultActor:
faultNode:
faultDetail:
    {http://xml.apache.org/axis/}hostname:xxxservernameherexxx

Reply to this Message

-==cfSearching==- - 13 May 2008 17:24 GMT

[I]Does this only work in CF8 ? [/I]

No. I tested your sample cfc locally with MX7. It produces the correct results

"CFSCRIPT Method 2
Good day my dear fellows
Invoke Method
Results:
Hello mates."

A cursory search did turn up a reference to the MX7 error:
http://www.luismajano.com/blog/index.cfm/2006/2/6/Could-not-resolve-CFC-datatype
-Error-when-viewing-a-cfcwsdl.

I can still view the wsdl and run the code. So I am not certain what is
causing the error. Have you checked the logs? It is possible they might
contain additional details that might help diagnose the problem. Other things
I would check are:

1. Are you able to view http://prod.trollsoftware.com/trollws.cfc?wsdl in
your browser?

2. Are you able to retrieve the wsdl with cfhttp
<cfhttp url="http://prod.trollsoftware.com/trollws.cfc?wsdl"/>
<cfdump var="#cfhttp#">

3. Are the results any different if you try #1 and #2 using the IP, instead
of prod.trollsoftware.com?

Reply to this Message

RLS - 13 May 2008 18:15 GMT

I found this wonderful forum post
http://www.adobe.com/cfusion/webforums/forum/messageview.cfm?catid=7&threadid=88
1689 and have been tyring to get it to run without removing the "/" mapping in
case that would "break" something on my production server. I've tried hard to
get Approach #2 to work as listed in that item, but to no avail. I can almost
always see the XML code, but CF never wants to find it as an object reference.

To answer your questions -- and thank you for your help on this! --
1. Yes. I can see the XML code just fine.
2. No. I get unknown host, connection failure, status not available.
3. Doesn't work with IP, but that was expected as there are many domains on
this server, not just this one.

So, to continue, I thought I'd back up and try it on my CF7 server. The
program runs from here [http://www.saphea.com/echotest.cfm] against the
WSDL/CFC file here [http://components.findaportal.com/wsdl/trollws.cfc?wsdl].
I can see the XML file just fine, but the echotest does not work (code
attached).

I created a mapping of "/wsdl" to "d:\clients\components\wsdl" in trying to
emulate Approach #2, and created a web subdomain of
http://components.findaportal.com to "d:\clients\components", but no dice.
Approach #2 may have to be abandoned.

Why would it work for you and not me? That's the weird part.

RLS

Primary snippet from echotest:

<cfscript>

    ws=CreateObject("webservice","http://components.findaportal.com/wsdl/trollws.cf
c?wsdl");
    wsresults=ws.echoString("Good day my dear fellows");
    writeoutput(wsresults);
</cfscript>

<h3>Invoke Method</h3>
<cfinvoke webservice="http://components.findaportal.com/wsdl/trollws.cfc?wsdl"
    method="echoString" input="Hello mates." returnvariable="foo" />

Reply to this Message

RLS - 13 May 2008 19:07 GMT

I think I've got it. If you can run http://www.saphea.com/echotest2.cfm
successfully, then I could have marked this as the answer except for the
troubling issue I ran into (below).

Before I detail my solution for any who may find this post, I need to add one
more tidbit that, in retrospect, may have been important to mention sooner. My
CF Mapping of "/" is pointing to c:\inetpub\wwwroot, but all of my web sites
are actually contained in a directory on another drive.

So, here's how I have almost resolved this on my CF7 server. I need to go try
it on the CF8 server yet.

1. Created directory "C:\Inetpub\wwwroot\cfwebservices". This is where the CFC
is placed.
2. In CF Admin, I mapped "/cfwebservices" to
"C:\inetpub\wwwroot\cfwebservices" (same directory as step #1).
3. Used the default web site name as the access to the cfc.

And that is the echotest2.cfm that you see above.

However, I then added the subdomain of "webservices.saphea.com" to the Default
web server so that I wasn't releasing my internal server name when I published
the services. Trouble rose again!

http://www.saphea.com/echotest3.cfm does not work. I can go to the ?wsdl file
and view it, and it looks just like the one I can see that echotest2 accesses,
but for some reason it doesn't want to work with the webservices subdomain.
Did I misspell something here? I don't think so!

Back to the drawing board.

RLS

Reply to this Message

RLS - 13 May 2008 21:24 GMT

Aha! It's not often that a "eureka moment" comes along, so I will celebrate it
a little bit.

I started thinking about the fact that I could get the service to work with my
ISP's domain name for my server, but not with my own, and the fact that
cfSearching could run it aok but I could not. I was thrown off by my co-worker
unable to run it, and I don't exactly have an answer for that.

But with all my mappings and trapping and what-not in place, I started
experimenting with different variations on the URL that was called, suddenly
realizing/assuming that I only needed to specify the path name since it was all
internal. That's when I realized that when you're inside the network
(firewall?) of the ISP, the IP number is radically different from the one the
rest of the world sees. When I have a local domain name call a service on the
same server, it's not going to travel outside of the firewall looking for that
service (http requests are different, I've learned; web services take a few
twists along the way and don't follow the normal rules.)

When I changed the URL to use the INTERNAL IP address (10.x.x.x), Voila!
Worked like a charm.

So, here's the problem now to be aware of in coding: when I call the service
from a domain INSIDE that same server, I need to use the internal IP, otherwise
I need to use the external IP.

My guess is that this may very well be the fix for a number of you having the
same issue.

Hope that helped.

RLS

Reply to this Message

-==cfSearching==- - 14 May 2008 12:59 GMT

Yes, that would explain it. Glad you solved it .. and thanks for posting the resolution :-) I am sure it will help someone else in the future.

Reply to this Message

Webmaster Forum / ColdFusion / Advanced Techniques / May 2008

Unable to read WSDL from URL