This content has been marked as final. Show 5 replies
What is the entire error message you're seeing?
Does an instance of it show up in the Administrator?
Can you post the code for both the web service and the consumer?
What OS are you on?
Try another web service in another directory (Possibly cf_root) with a return type of string just for kicks.
Well, I answered those questions already, I can't post the code, but the error is clearly defined in my post, as is my OS.
I dont understand why I get that error. I can view the WSDL file just fine, but always get this error.
> Well, I answered those questions already, I can't post the code, but the error
> is clearly defined in my post, as is my OS.
Talking like that to someone who's trying to help you is not going to win
you any friends. And probably very little help.
> I dont understand why I get that error. I can view the WSDL file just fine,
> but always get this error.
I have sometimes found this to happen when I have executed a WS once, and
then changed some of its input/output data types. I'm not entirely sure
what's going on, but deleting any files created in (I think)
WEB-INF\cfc-skeletons seemed to allow it to regenerate the stub files.
I would do what BSterner suggests... create another very simple WS (one
that takes a string arg, and returns a boolean, or something), and try
that: just to test if you can get ANY WSs working.
I have found that CF struggles with queries as datatypes in WSs, I guess
because it's not a supported datatype for WSs in general, being specific to
CF. I have not really looked at this since 6.1, though (I'm not really a
developer any more, so don't get to keep up to date with this stuff).
Thanks for the response, but I dont think my response was out of line at all. I merely stated I answered those questions because I clearly mentioned the Operating System I was using, and BSterner asked the question. I think I laid out my problem and even numbered the things that I have done. The first item on my list outlines the Operating System I am using.
I have always appreciated the help received on the forums.
Thanks for your response.
I have come across this error before and it was down to a NAT issue on our network setup. basically the route back to the calling machine is masked on the outgoing packet for security.
If you are running this from within a network then it may be worth testing it from a standalone machine connected directly to the internet.