Hi,
I ran into one of these issues sometime ago, in my case when parsing the xsds.
I am now at a stage when I really need to call some SOAP APIs, and need to make a decision. I would love to use SUDS for this project, and am dreading moving back to ZSI client.
I tried hacking the code, and also applying the patches that have been suggested in the related tickets, but that does not seem to help.
Is there any possibility this issue will be addressed in the near future?
Specifically, the error I am seeing (with the code from svn):
File "/export/home/gwilliams/suds/xsd/schema.py", line 298, in open_imports imported = imp.open(options) File "/export/home/gwilliams/suds/xsd/sxbasic.py", line 515, in open result = self.download(options) File "/export/home/gwilliams/suds/xsd/sxbasic.py", line 536, in download return self.schema.instance(root, url, options) File "/export/home/gwilliams/suds/xsd/schema.py", line 390, in instance return Schema(root, baseurl, options) File "/export/home/gwilliams/suds/xsd/schema.py", line 219, in __init__ self.open_imports(options) File "/export/home/gwilliams/suds/xsd/schema.py", line 298, in open_imports imported = imp.open(options) File "/export/home/gwilliams/suds/xsd/sxbasic.py", line 515, in open result = self.download(options) File "/export/home/gwilliams/suds/xsd/sxbasic.py", line 536, in download return self.schema.instance(root, url, options) File "/export/home/gwilliams/suds/xsd/schema.py", line 390, in instance
Many Thanks, Geraint.
Geraint Williams wrote, On 02/24/2010 04:29 AM:
Hi,
I ran into one of these issues sometime ago, in my case when parsing the xsds.
I am now at a stage when I really need to call some SOAP APIs, and need to make a decision. I would love to use SUDS for this project, and am dreading moving back to ZSI client.
I tried hacking the code, and also applying the patches that have been suggested in the related tickets, but that does not seem to help.
Is there any possibility this issue will be addressed in the near future?
Specifically, the error I am seeing (with the code from svn):
File "/export/home/gwilliams/suds/xsd/schema.py", line 298, in open_imports imported = imp.open(options) File "/export/home/gwilliams/suds/xsd/sxbasic.py", line 515, in open result = self.download(options) File "/export/home/gwilliams/suds/xsd/sxbasic.py", line 536, in download return self.schema.instance(root, url, options) File "/export/home/gwilliams/suds/xsd/schema.py", line 390, in instance return Schema(root, baseurl, options) File "/export/home/gwilliams/suds/xsd/schema.py", line 219, in __init__ self.open_imports(options) File "/export/home/gwilliams/suds/xsd/schema.py", line 298, in open_imports imported = imp.open(options) File "/export/home/gwilliams/suds/xsd/sxbasic.py", line 515, in open result = self.download(options) File "/export/home/gwilliams/suds/xsd/sxbasic.py", line 536, in download return self.schema.instance(root, url, options) File "/export/home/gwilliams/suds/xsd/schema.py", line 390, in instance
Many Thanks, Geraint.
I have been struggling with this, off and on, for several weeks.
My previous patches for handling circular WSDL-file importing just kept track of which WSDL files were already imported, and did not import the same file more than once.
That still seems to me to be a good strategy, but the changes made to the Suds base code, to integrate the caching, have made it considerably harder.
First, there are now several new layers of classes and their methods, through which it would be necessary to pass the list of already-imported files.
Second, I do not yet see how to make the "resolving" process work. The way it's written now, each WSDL file pulls in all its imports, then resolves the whole (self,imports) complex. That's going to fail for an imported file if some of its imports are not, at that stage, imported as *its* children, because they were already imported by a WSDL file further up the importing tree. In my old patches, I used a simple "don't resolve unless you're at top level" approach, but I don't see how to make that work in the current integrated-caching code.
It looks like the right approach will be to refactor the WSDL file-set loading process drastically, to import everything *without* resolving, merge the various loaded structures into One Big Unresolved Structure, then resolve *that*.
However, that refactoring must not derange the caching, and I don't yet understand the caching well enough.
I'm afraid it's going to take me weeks, rather than hours or days.