Skip to main content
RLS
RLS
Inspiring
May 9, 2008
Answered

Unable to read WSDL from URL

  • May 9, 2008
  • 2 replies
  • 10793 views
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
This topic has been closed for replies.
Correct answer RLS
I thought I solved it...byt,,,. 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
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

2 replies

RLS
RLSAuthor
Inspiring
May 13, 2008
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
-
-__cfSearching__-
Inspiring
May 13, 2008
RLS wrote:
Does this only work in CF8 ?

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: Could not resolve CFC datatype: Error when viewing a cfc?wsdl.

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?
RLS
RLSAuthor
Inspiring
May 13, 2008
I found this wonderful forum post {HERE}">http://www.adobe.com/cfusion/webforums/forum/messageview.cfm?catid=7&threadid=881689[/S 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

-
-__cfSearching__-
Inspiring
May 10, 2008
> 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 your 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?
RLS
RLSAuthor
Inspiring
May 13, 2008
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
Terms & ConditionsAccessibility statement
Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices