> here is the stack
> trace. i know that SOAPpy is doing wrong by not checking the type of
> the element along with id(ele).
> I thought if there is any work around the problem i could use that without
> upgrading SOAPpy after it is fixed.
Hi Premnath,
You might want to see if some other SOAP module might be better supported.
The last version of SOAPpy that I've seen appears to have been released in
2005, and as far as I can tell, the project is languishing a bit. Most of
the energy toward Python and SOAP seems to be focused on the Zolera SOAP
Infrastructure (ZSI) project, which can be found at:
http://pywebsvcs.sourceforge.net/
Thanks again for the stack trace; it helps pinpoint some problems. I did
some quick checks on the stack trace; the line numbers from the stack
trace aren't matching up with SOAPpy 0.12.0., so I'm not sure if this
problem has already been fixed or not. You may want to make sure you have
the latest release of SOAPpy if you continue using that module.
The code for SOAPBuilder.dump_string() just doesn't look right to me.
Why does one have to do a checkref() on it when serializing the string
data, given that a string has no internal structure to speak of? I think
the code there is just wrong. You're seeing this failure simply because
you're passing in two strings with the same id, which should be perfectly
legal and fine. SOAPpy is definitely at fault here.
I kludged up the recursive-checking code on strings (i.e. turned it off),
and now see the following:
##########################################################################
>>> import SOAPpy
>>> rmt = SOAPpy.SOAPProxy("http://soap.test.com";,
... header = SOAPpy.Types.headerType(
... data = {'username': 'prem',
... 'password': 'prem'}))
>>> rmt.testcall()
Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "SOAPpy/Client.py", line 470, in __call__
return self.__r_call(*args, **kw)
File "SOAPpy/Client.py", line 492, in __r_call
self.__hd, self.__ma)
File "SOAPpy/Client.py", line 363, in __call
config = self.config)
File "SOAPpy/Client.py", line 263, in call
raise HTTPError(code, msg)
SOAPpy.Errors.HTTPError: <HTTPError 405 Method not allowed>
##########################################################################
which looks a little more promising.
In fact, you can see this yourself by playing a small trick:
#######################################################################
>>> rmt = SOAPpy.SOAPProxy("http://soap.test.com";, header =
SOAPpy.Types.headerType(data={'username': 'p' + 'rem', 'password': 'p' +
'rem'}))
>>> rmt.testcall()
Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "SOAPpy/Client.py", line 470, in __call__
return self.__r_call(*args, **kw)
File "SOAPpy/Client.py", line 492, in __r_call
self.__hd, self.__ma)
File "SOAPpy/Client.py", line 363, in __call
config = self.config)
File "SOAPpy/Client.py", line 263, in call
raise HTTPError(code, msg)
SOAPpy.Errors.HTTPError: <HTTPError 405 Method not allowed>
#######################################################################
Forcing the manual string concatenation lets you go on, but this is just a
silly kludge around what is fundamentally a bad SOAPYpy bug.
My current recommendation is to try using ZSI instead: the SOAPpy code
base appears to have a bit of bit rot.
Good luck to you!
_______________________________________________
Tutor maillist - Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor
