From jortel at redhat.com Mon May 12 13:37:50 2008 From: jortel at redhat.com (Jeff Ortel) Date: Mon, 12 May 2008 09:37:50 -0400 Subject: [Fedora-suds-list] Test Message-ID: <4828482E.2010705@redhat.com> Test -- Jeff Ortel RHN Satellite Engineering Centennial (324D) (P) 919-754-4603 From jortel at redhat.com Mon May 12 13:52:07 2008 From: jortel at redhat.com (Jeff Ortel) Date: Mon, 12 May 2008 09:52:07 -0400 Subject: [Fedora-suds-list] Test Message-ID: <48284B87.2010106@redhat.com> Test -- Jeff Ortel RHN Satellite Engineering Centennial (324D) (P) 919-754-4603 From ph.silva at gmail.com Thu May 15 06:51:55 2008 From: ph.silva at gmail.com (Paulo Henrique Silva) Date: Thu, 15 May 2008 03:51:55 -0300 Subject: [Fedora-suds-list] Unmarshaller problem?! Message-ID: <9d9acabc0805142351g8e6dffaiac7af7a552860e7e@mail.gmail.com> Hi guys, I'm getting a strange bug using suds on this service http://cdsws.u-strasbg.fr/axis/services/Sesame?wsdl. My code is something like: proxy = ServiceProxy(Simbad.WSDL) print proxy.sesame ('M51', 'x') and the result is something like: UFOZero (0) answers*** This identifier is not present in the database: NAME UFOZero (0) answersNo table found for: UFOZero (0) answers!***Connection to Ned crashed Here is the problem: Note that there are no spaces between version and encoding attributes on <?xml version="1.0" encoding="UTF-8"?> <Sesame xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="http://vizier.u-strasbg.fr/xml/sesame_2.xsd"> <!-- Q28920 --> <target>UFO</target> <Resolver name="Simbad"> <INFO>Zero (0) answers</INFO> <INFO>*** This identifier is not present in the database: NAME UFO</INFO> </Resolver> <Resolver name="VizieR"> <INFO>Zero (0) answers</INFO> <INFO>No table found for: UFO</INFO> </Resolver> <Resolver name="Ned"> <INFO>Zero (0) answers</INFO> <INFO>!***Connection to Ned crashed </INFO> </Resolver> </Sesame> >From this, seems that somewhere in the unmarshaller, the \n are replaced and all the lines are stripped, making the errors cited above. While I was writing this I found that on sax.py:Handler.characters there is a strip call! If I remove that strip, everything goes well! Is that strip really necessary or is this a bug? Thanks a lot, -- Paulo Henrique From jortel at redhat.com Thu May 15 14:07:58 2008 From: jortel at redhat.com (Jeff Ortel) Date: Thu, 15 May 2008 10:07:58 -0400 Subject: [Fedora-suds-list] Unmarshaller problem?! In-Reply-To: <9d9acabc0805142351g8e6dffaiac7af7a552860e7e@mail.gmail.com> References: <9d9acabc0805142351g8e6dffaiac7af7a552860e7e@mail.gmail.com> Message-ID: <482C43BE.3010103@redhat.com> Hey Paulo, Thanks for your interest in Suds. I'm glad to hear you find it helpful. The strip() was intended to mitigate the annoying text nodes produced by "pretty" formatted XML. However, in reality, soap servers don't format the XML and, as you point out, having the strip() causes problems. Great catch! I'll remove the strip() on trunk asap and post a notice on the mailing list. Thanks again, Regards, Jeff Paulo Henrique Silva wrote: > Hi guys, > > I'm getting a strange bug using suds on this service > http://cdsws.u-strasbg.fr/axis/services/Sesame?wsdl. > > My code is something like: > > proxy = ServiceProxy(Simbad.WSDL) > print proxy.sesame ('M51', 'x') > > and the result is something like: > > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xsi:noNamespaceSchemaLocation="http://vizier.u-strasbg.fr/xml/sesame_2.xsd">UFOZero (0) > answers*** This identifier is not present in the > database: NAME UFOZero > (0) answersNo table found for: > UFOZero (0) > answers!***Connection to Ned > crashed > > Here is the problem: Note that there are no spaces between version and > encoding attributes on there are no spaces between two xsi declarations. This make this XML > not well formed and no parser accept to digest this. > > When I turn debug on, I see this: > > 2008-05-15 03:38:16,747 {12055} (serviceproxy.py, 267) [DEBUG] http succeeded: > xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" > xmlns:xsd="http://www.w3.org/2001/XMLSchema" > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" > xmlns:ns1="urn:Sesame"><?xml > version="1.0" encoding="UTF-8"?> > <Sesame xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xsi:noNamespaceSchemaLocation="http://vizier.u-strasbg.fr/xml/sesame_2.xsd"> > <!-- Q28920 --> > <target>UFO</target> > <Resolver name="Simbad"> > <INFO>Zero (0) answers</INFO> > <INFO>*** This identifier is not present in the database: > NAME UFO</INFO> > </Resolver> > <Resolver name="VizieR"> > <INFO>Zero (0) answers</INFO> > <INFO>No table found for: UFO</INFO> > </Resolver> > <Resolver name="Ned"> > <INFO>Zero (0) answers</INFO> > <INFO>!***Connection to Ned crashed </INFO> > </Resolver> > </Sesame> > > >>From this, seems that somewhere in the unmarshaller, the \n are > replaced and all the lines are stripped, making the errors cited > above. > > While I was writing this I found that on sax.py:Handler.characters > there is a strip call! If I remove that strip, everything goes well! > Is that strip really necessary or is this a bug? > > Thanks a lot, > > -- Paulo Henrique > > _______________________________________________ > fedora-suds-list mailing list > fedora-suds-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-suds-list -- Jeff Ortel RHN Satellite Engineering Centennial (324D) (P) 919-754-4603 From jortel at redhat.com Thu May 15 14:25:50 2008 From: jortel at redhat.com (Jeff Ortel) Date: Thu, 15 May 2008 10:25:50 -0400 Subject: [Fedora-suds-list] trunk patched (r122) Message-ID: <482C47EE.5030202@redhat.com> All, A patch has been applied to trunk (r122) to remove the strip() when processing (text) characters in the sax handler. Regards, Jeff From jesper at noehr.org Fri May 16 07:23:29 2008 From: jesper at noehr.org (Jesper Noehr) Date: Fri, 16 May 2008 09:23:29 +0200 Subject: [Fedora-suds-list] Proposal to add .innerXML attribute to Object Message-ID: Hello list, As per discussion with kurazu on IRC this morning, and per http://msdn.microsoft.com/hi-in/library/ms440289(en-us).aspx it seems necessary in some cases to allow for people to construct arbitrary content of nodes. The problem here being that the aforementioned API requires you to set XML as content for a value. Right now, suds will automatically escape the XML. What I propose is to add a new "magic" attribute to Objects, called `innerXML` which would make an instance of `safestring` which is a subclass of unicode. This subclass would have a new attribute, `safe` and when the marshaller encounters the object to marshal, it will omit the escaping if this attribute is present (and True.) You may also create instances of `safestring` anywhere else, and e.g. use it as the value of a property in something returned by get_instance. I don't like it much either, but I think this the cleanest way of getting around it. Jesper From tomasz.mackowiak at altcontrol.pl Fri May 16 07:45:15 2008 From: tomasz.mackowiak at altcontrol.pl (Tomasz =?utf-8?q?Ma=C4=87kowiak?=) Date: Fri, 16 May 2008 09:45:15 +0200 Subject: [Fedora-suds-list] Proposal to add .innerXML attribute to Object Message-ID: <200805160945.15379.tomasz.mackowiak@altcontrol.pl> This is how i would like it to work: whole = factory.get_instance('s:any') field = ... #contruct suds.sudsobject.Object field.ID = 5 field.innerXML = 'bar' whole.field = field should be output not as but as bar The contents of innerXML should be escaped. -- Z powa?aniem / Best regards Tomasz Ma?kowiak From pcaro at yaco.es Fri May 16 08:12:52 2008 From: pcaro at yaco.es (Pablo Caro Revuelta) Date: Fri, 16 May 2008 10:12:52 +0200 Subject: [Fedora-suds-list] An error in wsdl parsing? Message-ID: <200805161012.52354.pcaro@yaco.es> Hello Is the first time I am trying connect to a soap web service using using python. Existing libraries are very poor in my opinion (mainly by the interface) but I like suds and would like use it because is very pleasant. But I have a problem with the concrete serviece I need to use and I didn't find the solution. The service description is: https://freeway.demo.lionbridge.com/vojo/FreewayAuth.asmx?WSDL and I neet call to "Logon" function. The service runs correctly (I can use it with ZSI) I tried: {{{ vojo_auth_uri = "https://freeway.demo.lionbridge.com/vojo/FreewayAuth.asmx?wsdl" logger('suds.serviceproxy').setLevel(logging.DEBUG) auth_proxy = ServiceProxy(vojo_auth_uri) logon = auth_proxy.get_instance('Logon') logon.Username.append("user") logon.Password.append("password") print auth_proxy.Logon(logon) }}} When I run that code I get this error "You must specify both your username and password.at FreewayAuth.Logon(String Username, String Password)" The problem is that suds does NOT send a correct xml. The service expects (as documented in https://freeway.demo.lionbridge.com/vojo/FreewayAuth.asmx?op=Logon ): string string But the library send: user password The error: Note the extra Username tag. Am I using the library correctly? Is an library error? Thanks in advance PD: Please excuse my bad english -- Pablo Caro Revuelta pcaro at yaco.es Yaco Sistemas S.L. http://www.yaco.es C/ Sierpes 48, 41004 Sevilla (Espa?a) Tel?fono: 954 50 00 57 Fax 954 50 09 29 Este mensaje y sus documentos anexos son confidenciales y dirigidos exclusivamente a los destinatarios de los mismos. Si por error, ha recibido este mensaje y no es el destinatario, por favor, notif?queselo al remitente y no use, informe, distribuya, imprima, copie o difunda este mensaje por ning?n medio. This message and any attached files are confidential. They are for the intended recipients only. If an error has misdirected this e-mail to you, please, notify the author and do not use, disclose, distribute, copy, print or relay this e-mail. From jesper at noehr.org Fri May 16 08:28:29 2008 From: jesper at noehr.org (Jesper Noehr) Date: Fri, 16 May 2008 10:28:29 +0200 Subject: [Fedora-suds-list] An error in wsdl parsing? In-Reply-To: <200805161012.52354.pcaro@yaco.es> References: <200805161012.52354.pcaro@yaco.es> Message-ID: Hello Pablo, I tried analyzing the WSDL you gave, and it seems that the "Logon" method does not take a "Logon" instance, but two strings; username and password. Here's my code: import logging from suds.serviceproxy import ServiceProxy p = ServiceProxy('freeway.wsdl') logging.getLogger('suds.serviceproxy').setLevel(logging.DEBUG) print p.Logon('foo', 'bar') And here's what suds sends: foo bar The service still raises an error: faultstring = (System.Web.Services.Protocols.SoapException: You must specify both your username and password.at FreewayAuth.Logon(String Username, String Password)) ...but that might be due to the wrong username and password? HTH, Jesper On May 16, 2008, at 10:12 AM, Pablo Caro Revuelta wrote: > > Hello > > Is the first time I am trying connect to a soap web service using > using > python. Existing libraries are very poor in my opinion (mainly by the > interface) but I like suds and would like use it because is very > pleasant. > But I have a problem with the concrete serviece I need to use and I > didn't > find the solution. > > The service description is: > https://freeway.demo.lionbridge.com/vojo/FreewayAuth.asmx?WSDL > and I neet call to "Logon" function. > The service runs correctly (I can use it with ZSI) > > I tried: > > {{{ > vojo_auth_uri > = "https://freeway.demo.lionbridge.com/vojo/FreewayAuth.asmx?wsdl" > logger('suds.serviceproxy').setLevel(logging.DEBUG) > auth_proxy = ServiceProxy(vojo_auth_uri) > logon = auth_proxy.get_instance('Logon') > logon.Username.append("user") > logon.Password.append("password") > print auth_proxy.Logon(logon) > > }}} > > When I run that code I get this error "You must specify both your > username and > password.at FreewayAuth.Logon(String Username, String Password)" > > The problem is that suds does NOT send a correct xml. > The service expects (as documented in > https://freeway.demo.lionbridge.com/vojo/FreewayAuth.asmx?op=Logon ): > > > xmlns:xsd="http://www.w3.org/2001/XMLSchema" > xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> > > > string > string > > > > > But the library send: > > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xmlns:tns="http://tempuri.org/" > xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> > > > > user > password > > > > > > The error: Note the extra Username tag. > > Am I using the library correctly? Is an library error? > > Thanks in advance > > PD: Please excuse my bad english > > -- > > Pablo Caro Revuelta > pcaro at yaco.es > > Yaco Sistemas S.L. > http://www.yaco.es > C/ Sierpes 48, 41004 Sevilla (Espa?a) > Tel?fono: 954 50 00 57 > Fax 954 50 09 29 > > > Este mensaje y sus documentos anexos son confidenciales y dirigidos > exclusivamente a los destinatarios de los mismos. Si por error, ha > recibido > este mensaje y no es el destinatario, por favor, notif?queselo al > remitente y > no use, informe, distribuya, imprima, copie o difunda este mensaje > por ning?n > medio. > > This message and any attached files are confidential. They are for the > intended recipients only. If an error has misdirected this e-mail to > you, > please, notify the author and do not use, disclose, distribute, > copy, print > or relay this e-mail. > > > _______________________________________________ > fedora-suds-list mailing list > fedora-suds-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-suds-list From pcaro at yaco.es Fri May 16 09:01:46 2008 From: pcaro at yaco.es (Pablo Caro Revuelta) Date: Fri, 16 May 2008 11:01:46 +0200 Subject: [Fedora-suds-list] An error in wsdl parsing? In-Reply-To: References: <200805161012.52354.pcaro@yaco.es> Message-ID: <200805161101.46909.pcaro@yaco.es> Hello Jesper, Thank you very much for your response. A response in 15 minutes! I really want to use suds :-D I tested the code you send me with the correct username and password but I have the same error. I dont know why because It looks like a correct xml. Maybe you can help me better if I give you more information. The ZSI code that works is: {{{ from FreewayAuth_services import * fp = open('debug.out', 'a') proxy = FreewayAuthLocator().getFreewayAuthSoap(tracefile=fp) logon = LogonSoapIn() logon._Username = user logon._Password = password ticket = proxy.Logon(logon) print ticket._LogonResult fp.close() }}} where FreewayAuth_services came from wsdl2py -u https://freeway.demo.lionbridge.com/vojo/FreewayAuth.asmx?WSDL The xmls in debug.out is: USERBLABLA The xml output is diferent, maybe ZSI runs because it use namespaces. How can I do it with suds? Cheers El Viernes 16 May 2008, Jesper Noehr escribi?: > Hello Pablo, > > I tried analyzing the WSDL you gave, and it seems that the "Logon" > method does not take a "Logon" instance, but two strings; username and > password. > > Here's my code: > > import logging > from suds.serviceproxy import ServiceProxy > > p = ServiceProxy('freeway.wsdl') > logging.getLogger('suds.serviceproxy').setLevel(logging.DEBUG) > > print p.Logon('foo', 'bar') > > > And here's what suds sends: > > xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/ " > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xmlns:tns="http://tempuri.org/ " > xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> > > > foo > bar > > > > > > The service still raises an error: > faultstring = (System.Web.Services.Protocols.SoapException: You must > specify both your username and password.at FreewayAuth.Logon(String > Username, String Password)) > > ...but that might be due to the wrong username and password? > > HTH, > Jesper > -- Pablo Caro Revuelta pcaro at yaco.es Yaco Sistemas S.L. http://www.yaco.es C/ Sierpes 48, 41004 Sevilla (Espa?a) Tel?fono: 954 50 00 57 Fax 954 50 09 29 Este mensaje y sus documentos anexos son confidenciales y dirigidos exclusivamente a los destinatarios de los mismos. Si por error, ha recibido este mensaje y no es el destinatario, por favor, notif?queselo al remitente y no use, informe, distribuya, imprima, copie o difunda este mensaje por ning?n medio. This message and any attached files are confidential. They are for the intended recipients only. If an error has misdirected this e-mail to you, please, notify the author and do not use, disclose, distribute, copy, print or relay this e-mail. From jesper at noehr.org Fri May 16 09:17:57 2008 From: jesper at noehr.org (Jesper Noehr) Date: Fri, 16 May 2008 11:17:57 +0200 Subject: [Fedora-suds-list] An error in wsdl parsing? In-Reply-To: <200805161101.46909.pcaro@yaco.es> References: <200805161012.52354.pcaro@yaco.es> <200805161101.46909.pcaro@yaco.es> Message-ID: Hi Pablo, I see the error here, the problem is that the service expects fully qualified namespacing on the elements (ns1:Username vs. Username). This is specified in your WSDL by elementFormDefault="qualified". This is a known issue and Jeff is working on a fix. It should be in trunk soon. Jeff, perhaps you could reply to this message when you've committed a fix and Pablo can test it? Jesper On May 16, 2008, at 11:01 AM, Pablo Caro Revuelta wrote: > > Hello Jesper, > > Thank you very much for your response. A response in 15 minutes! I > really want > to use suds :-D > > I tested the code you send me with the correct username and password > but I > have the same error. > I dont know why because It looks like a correct xml. > > Maybe you can help me better if I give you more information. > The ZSI code that works is: > {{{ > from FreewayAuth_services import * > fp = open('debug.out', 'a') > proxy = FreewayAuthLocator().getFreewayAuthSoap(tracefile=fp) > logon = LogonSoapIn() > logon._Username = user > logon._Password = password > ticket = proxy.Logon(logon) > print ticket._LogonResult > fp.close() > }}} > where FreewayAuth_services came from > wsdl2py -u https://freeway.demo.lionbridge.com/vojo/FreewayAuth.asmx?WSDL > > The xmls in debug.out is: > > xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" > xmlns:ZSI="http://www.zolera.com/schemas/ZSI/" > xmlns:xsd="http://www.w3.org/2001/XMLSchema" > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> ENV:Header> xmlns:ns1="http://tempuri.org/">USER ns1:Username>BLABLA ENV:Body> > > The xml output is diferent, maybe ZSI runs because it use > namespaces. How can > I do it with suds? > > Cheers > > El Viernes 16 May 2008, Jesper Noehr escribi?: >> Hello Pablo, >> >> I tried analyzing the WSDL you gave, and it seems that the "Logon" >> method does not take a "Logon" instance, but two strings; username >> and >> password. >> >> Here's my code: >> > >> import logging >> from suds.serviceproxy import ServiceProxy >> >> p = ServiceProxy('freeway.wsdl') >> logging.getLogger('suds.serviceproxy').setLevel(logging.DEBUG) >> >> print p.Logon('foo', 'bar') >> >> >> And here's what suds sends: >> >> > xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/ " >> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" >> xmlns:tns="http://tempuri.org/ " >> xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> >> >> >> foo >> bar >> >> >> >> >> >> The service still raises an error: >> faultstring = (System.Web.Services.Protocols.SoapException: You must >> specify both your username and password.at FreewayAuth.Logon(String >> Username, String Password)) >> >> ...but that might be due to the wrong username and password? >> >> HTH, >> Jesper >> > > > > -- > > Pablo Caro Revuelta > pcaro at yaco.es > > Yaco Sistemas S.L. > http://www.yaco.es > C/ Sierpes 48, 41004 Sevilla (Espa?a) > Tel?fono: 954 50 00 57 > Fax 954 50 09 29 > > > Este mensaje y sus documentos anexos son confidenciales y dirigidos > exclusivamente a los destinatarios de los mismos. Si por error, ha > recibido > este mensaje y no es el destinatario, por favor, notif?queselo al > remitente y > no use, informe, distribuya, imprima, copie o difunda este mensaje > por ning?n > medio. > > This message and any attached files are confidential. They are for the > intended recipients only. If an error has misdirected this e-mail to > you, > please, notify the author and do not use, disclose, distribute, > copy, print > or relay this e-mail. > > > _______________________________________________ > fedora-suds-list mailing list > fedora-suds-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-suds-list From pcaro at yaco.es Fri May 16 09:40:51 2008 From: pcaro at yaco.es (Pablo Caro Revuelta) Date: Fri, 16 May 2008 11:40:51 +0200 Subject: [Fedora-suds-list] An error in wsdl parsing? In-Reply-To: References: <200805161012.52354.pcaro@yaco.es> <200805161101.46909.pcaro@yaco.es> Message-ID: <200805161140.51225.pcaro@yaco.es> Hello, When jeff send commit the fix, I will be pleased testing it. cheers! El Viernes 16 May 2008, Jesper Noehr escribi?: > Hi Pablo, > > I see the error here, the problem is that the service expects fully > qualified namespacing on the elements (ns1:Username vs. Username). > This is specified in your WSDL by elementFormDefault="qualified". This > is a known issue and Jeff is working on a fix. It should be in trunk > soon. > > Jeff, perhaps you could reply to this message when you've committed a > fix and Pablo can test it? > > > > Jesper > -- Pablo Caro Revuelta pcaro at yaco.es Yaco Sistemas S.L. http://www.yaco.es C/ Sierpes 48, 41004 Sevilla (Espa?a) Tel?fono: 954 50 00 57 Fax 954 50 09 29 From jortel at redhat.com Fri May 16 18:29:38 2008 From: jortel at redhat.com (Jeff Ortel) Date: Fri, 16 May 2008 14:29:38 -0400 Subject: [Fedora-suds-list] An error in wsdl parsing? In-Reply-To: References: <200805161012.52354.pcaro@yaco.es> <200805161101.46909.pcaro@yaco.es> Message-ID: <482DD292.6040806@redhat.com> Yes, definitely. I'll post to the list when I have the defaultElementForm stuff committed. Jesper Noehr wrote: > Hi Pablo, > > I see the error here, the problem is that the service expects fully > qualified namespacing on the elements (ns1:Username vs. Username). This > is specified in your WSDL by elementFormDefault="qualified". This is a > known issue and Jeff is working on a fix. It should be in trunk soon. > > Jeff, perhaps you could reply to this message when you've committed a > fix and Pablo can test it? > > > > Jesper > > On May 16, 2008, at 11:01 AM, Pablo Caro Revuelta wrote: >> >> Hello Jesper, >> >> Thank you very much for your response. A response in 15 minutes! I >> really want >> to use suds :-D >> >> I tested the code you send me with the correct username and password >> but I >> have the same error. >> I dont know why because It looks like a correct xml. >> >> Maybe you can help me better if I give you more information. >> The ZSI code that works is: >> {{{ >> from FreewayAuth_services import * >> fp = open('debug.out', 'a') >> proxy = FreewayAuthLocator().getFreewayAuthSoap(tracefile=fp) >> logon = LogonSoapIn() >> logon._Username = user >> logon._Password = password >> ticket = proxy.Logon(logon) >> print ticket._LogonResult >> fp.close() >> }}} >> where FreewayAuth_services came from >> wsdl2py -u >> https://freeway.demo.lionbridge.com/vojo/FreewayAuth.asmx?WSDL >> >> The xmls in debug.out is: >> >> > xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" >> xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" >> xmlns:ZSI="http://www.zolera.com/schemas/ZSI/" >> xmlns:xsd="http://www.w3.org/2001/XMLSchema" >> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">> >> xmlns:ns1="http://tempuri.org/">USERBLABLA >> >> >> The xml output is diferent, maybe ZSI runs because it use namespaces. >> How can >> I do it with suds? >> >> Cheers >> >> El Viernes 16 May 2008, Jesper Noehr escribi?: >>> Hello Pablo, >>> >>> I tried analyzing the WSDL you gave, and it seems that the "Logon" >>> method does not take a "Logon" instance, but two strings; username and >>> password. >>> >>> Here's my code: >>> >> >>> import logging >>> from suds.serviceproxy import ServiceProxy >>> >>> p = ServiceProxy('freeway.wsdl') >>> logging.getLogger('suds.serviceproxy').setLevel(logging.DEBUG) >>> >>> print p.Logon('foo', 'bar') >>> >>> >>> And here's what suds sends: >>> >>> >> xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/ " >>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" >>> xmlns:tns="http://tempuri.org/ " >>> xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> >>> >>> >>> foo >>> bar >>> >>> >>> >>> >>> >>> The service still raises an error: >>> faultstring = (System.Web.Services.Protocols.SoapException: You must >>> specify both your username and password.at FreewayAuth.Logon(String >>> Username, String Password)) >>> >>> ...but that might be due to the wrong username and password? >>> >>> HTH, >>> Jesper >>> >> >> >> >> -- >> >> Pablo Caro Revuelta >> pcaro at yaco.es >> >> Yaco Sistemas S.L. >> http://www.yaco.es >> C/ Sierpes 48, 41004 Sevilla (Espa?a) >> Tel?fono: 954 50 00 57 >> Fax 954 50 09 29 >> >> >> Este mensaje y sus documentos anexos son confidenciales y dirigidos >> exclusivamente a los destinatarios de los mismos. Si por error, ha >> recibido >> este mensaje y no es el destinatario, por favor, notif?queselo al >> remitente y >> no use, informe, distribuya, imprima, copie o difunda este mensaje por >> ning?n >> medio. >> >> This message and any attached files are confidential. They are for the >> intended recipients only. If an error has misdirected this e-mail to you, >> please, notify the author and do not use, disclose, distribute, copy, >> print >> or relay this e-mail. >> >> >> _______________________________________________ >> fedora-suds-list mailing list >> fedora-suds-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-suds-list > > > _______________________________________________ > fedora-suds-list mailing list > fedora-suds-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-suds-list -- Jeff Ortel RHN Satellite Engineering Centennial (324D) (P) 919-754-4603 From jortel at redhat.com Mon May 19 16:32:56 2008 From: jortel at redhat.com (Jeff Ortel) Date: Mon, 19 May 2008 12:32:56 -0400 Subject: [Fedora-suds-list] development update Message-ID: <4831ABB8.5030109@redhat.com> All, I'd like to briefly update everyone on some of the things I'm currently working on: In order to support the new features and fix reported bugs, I'm in the process of refactoring and hopefully evolving the components in Suds that provide the input/output translations: * Builder ( translates: XSD objects => python objects ) * Marshaller ( translates: python objects => XML/SOAP ) * Unmarshaller ( translates: soap/xml => python objects ) This evolution will provide better symmetry between these components as follows: The Builder and Unmarshaller will produce python (subclass of sudsobject.Object) objects with: * __metadata__.__type__ = XSD type (SchemaProperty) * subclass name ( __class__.__name__ ) = schema-type name. and The Marshaller(s), while consuming python objects produced by the Builder or Unmarshaller, will leverage this standard information to produce the appropriate output ( XML/SOAP ). The 0.2.1 code behaves *mostly* like this but ... not quite. Also, the implementations have some redundancy. While doing this, it made sense to factor out the common schema-type "lookup" functionality used by the Builder, Marshallers and Unmarshaller classes into a hierarchy of "Resolver" classes. This reduces the complexity and redundancy of the Builder, Marshallers and Unmarshaller classes and allows for better modularity. Once this refactoring was complete, the difference between the literal/encoded Marshallers became very small. Given that the amount of code in the bindings.literal and bindings.encoded packages was small (and getting smaller) and in the interest of keeping the Suds code base compact, I moved all of the marshalling classes to the bindings.marshaller module. All of the bindings.XX sub-packages will be removed. The net effect: All of the Suds major components: * service proxy * wsdl * schema * resolvers * output (marshalling) * builder * input (unmarshalling) Now have better: * modularity * symmetry with regard to Object metadata. * code re-use (< 1% code duplication --- i hope) * looser coupling ... and better provide for the following features/bug-fixes: * (fix) Proper level of XML element qualification based on attribute. This will ensure that when elementFormDefault="qualified", Suds will include the proper namespace on root elements for both literal and encoded bindings. In order for this to work properly, the literal marshaller (like the encoded marshaller) needed to be schema-type aware. Had i added the same schema-type lookup as the encoded marshaller instead of the refactoring described above, the two classes would have been almost a complete duplicate of each other :-( * (enhancement) The builder and unmarshaller used the schema.Schema.find() to resolve schema-types. They constructed a path as "person.name.first" to resolve types in proper context. Since the Schema.find() was stateless, it resolved the intermediate path elements on every call. The new resolver classes are statefull and resolve child types *much* more efficiently. * (enhancement) Add a metadata flag so that marshaller will ouput innerXML as escaped TEXT content instead of child nodes. * (future-feature) have the marshaller/unmarshallers do python<=> xs type conversions such as xs:date, xs:datetime etc ..... Other fixes in my workspace waiting to be commited: * (fix/enhancement) Name collisions in sudsobject.Object like the items() method. I've moved all methods (including class methods) to a Factory class that is included in the Object class as a class attr ( __factory__ ). Now that *all* attributes have python built-in naming, we should not have any more name collisions. This of course assumes that no wsdl/schema entity names will have a name with the python built-in naming convention but I have to draw the line somewhere :-) I'm pretty jammed at work right now so my time to work on suds is limited. I have all of these changes and fixes coded and mostly tested. Once, completely regression tested, I'll release to trunk. If you're waiting on what seems like a simple fix to hit truck, it's probably been completed but because it's mixed in these larger changes, it's been delayed reaching trunk. Also, I'm going to try and get a public bugzilla site setup to track features and bugs. As the suds community get larger and larger, my ability to properly track these things (on top of my current work load) is getting stretched. I need the community to help me and access to a public facility such as bugzilla would really help. If you feel that your bug or feature request has "slipped through the cracks", I apologize. For now, please remind me on the list. Thanks to everyone for your interest and help with suds, Jeff From jortel at redhat.com Tue May 20 13:48:32 2008 From: jortel at redhat.com (Jeff Ortel) Date: Tue, 20 May 2008 09:48:32 -0400 Subject: [Fedora-suds-list] Suds Ticketing System Message-ID: <4832D6B0.3040106@redhat.com> All, I've setup the suds trac project ( https://fedorahosted.org/suds ) to expose the ticketing system to anonymous users. This should provide a good way to track suds features and defects. I've gone back over emails and created tickets on behalf of the author of the email. Please review the tickets to be sure that I haven't omitted or misrepresented anything. Since anonymous can create/edit/append tickets, please feel free to correct/augment existing tickets and add any missing tickets. There is no need to send me an email when you create/edit a ticket. I get an email automatically. Also, be sure to fill in the field "Your email or username:" if you want to get emails as the ticket is processed. See links at the top of the (trac) project page. TO VIEW TICKETS: View Tickets -> Active Tickets Then, select ticket to view details. TO CREATE A NEW TICKET: New Ticket Then, * Change the "Your email or username:" field replace "annonyous" with YOUR email address. * Fill in the "Summary" * Fill in "Full Description" MODIFY A TICKET: View Tickets -> Active Tickets Then, select ticket to view details for modify. **note: Change the "Your email or username:" field replace "annonyous" with YOUR email address. Thanks, Jeff -- Jeff Ortel Principal Engineer Red Hat, Inc. Raleigh, North Carolina www.redhat.com From ryates100 at gmail.com Wed May 21 02:09:36 2008 From: ryates100 at gmail.com (Rob Yates) Date: Tue, 20 May 2008 22:09:36 -0400 Subject: [Fedora-suds-list] .NET Namespace Issue Message-ID: <48338460.7010903@gmail.com> Hey all. I know this isn't a .NET support group, but I was hoping someone could help me with I'm probably I'm having trying to get suds to work with a .NET SOAP service. I'm using version in tags/release-0.2 since the trunk version can't even parse my WSDL. When sending the POST via suds, here is what my SOAP XML looks like: myUsername myPassword which gives me a useless .NET error which is the equivelant of a generic 500 server error: System.Web.Services.Protocols.SoapException: Server was unable to process request. ---> System.NullReferenceException: Object reference not set to an instance of an object. I was able to get the error to go away by simple dropping the tns namespace from the Login node and adding xmlns attribute instead: myUsername myPassword As I'm fairly namespace-challenged, any ideas why this may be happening? Thanks in advance for any assistance. I'd be happy to send the WSDL via e-mail to whoever may want to take a look. -Rob (Fairbanks) From gary.wilson at gmail.com Wed May 21 03:25:06 2008 From: gary.wilson at gmail.com (Gary Wilson Jr.) Date: Tue, 20 May 2008 22:25:06 -0500 Subject: [Fedora-suds-list] .NET Namespace Issue In-Reply-To: <48338460.7010903@gmail.com> References: <48338460.7010903@gmail.com> Message-ID: <48339612.5090806@gmail.com> Rob Yates wrote: > As I'm fairly namespace-challenged, any ideas why this may be > happening? Thanks in advance for any assistance. > I'd be happy to send the WSDL via e-mail to whoever may want to take a > look. I'm having the same problem as you :) and I believe this is the issue: https://fedorahosted.org/suds/ticket/7 Jeff Ortel mentioned in an email to the list yesterday [1] that he has fixed the issue in his development code and that it will be put in trunk after some testing. The relevant snippet of that email: ------ * (fix) Proper level of XML element qualification based on attribute. This will ensure that when elementFormDefault="qualified", Suds will include the proper namespace on root elements for both literal and encoded bindings. In order for this to work properly, the literal marshaller (like the encoded marshaller) needed to be schema-type aware. Had i added the same schema-type lookup as the encoded marshaller instead of the refactoring described above, the two classes would have been almost a complete duplicate of each other :-( ------ I was building a fairly complex SOAP request the other day, and was going crazy trying to figure out why I was only getting a 500 error response back no matter what I tried. Jeff's email yesterday was a relief. I just introduced myself to SOAP a couple days ago, and I must say that I like suds and it's interface much more than the other libraries I tried (SOAPpy and ZSI). FYI, SOAPpy seems to have the same namespace problems (I didn't fully test ZSI). Keep up the good work guys! Gary [1] https://www.redhat.com/archives/fedora-suds-list/2008-May/msg00013.html From ryates100 at gmail.com Wed May 21 04:40:52 2008 From: ryates100 at gmail.com (Rob Yates) Date: Wed, 21 May 2008 00:40:52 -0400 Subject: [Fedora-suds-list] .NET Namespace Issue In-Reply-To: <48339612.5090806@gmail.com> References: <48338460.7010903@gmail.com> <48339612.5090806@gmail.com> Message-ID: <4833A7D4.2080606@gmail.com> Gary - Thanks for the reply, good information. I have had no better luck in ZSI or SOAPpy with this particular web service either. -Rob Gary Wilson Jr. wrote: > Rob Yates wrote: >> As I'm fairly namespace-challenged, any ideas why this may be >> happening? Thanks in advance for any assistance. >> I'd be happy to send the WSDL via e-mail to whoever may want to take >> a look. > > I'm having the same problem as you :) and I believe this is the issue: > > https://fedorahosted.org/suds/ticket/7 > > Jeff Ortel mentioned in an email to the list yesterday [1] that he has > fixed the issue in his development code and that it will be put in > trunk after some testing. The relevant snippet of that email: > > ------ > * (fix) Proper level of XML element qualification based on elementFormDefault=""/> attribute. This will ensure that when > elementFormDefault="qualified", Suds will include the proper namespace > on root elements for both literal and encoded bindings. In order for > this to work properly, the literal marshaller (like the encoded > marshaller) needed to be schema-type aware. Had i added the same > schema-type lookup as the encoded marshaller instead of the > refactoring described above, the two classes would have been almost a > complete duplicate of each other :-( > ------ > > I was building a fairly complex SOAP request the other day, and was > going crazy trying to figure out why I was only getting a 500 error > response back no matter what I tried. Jeff's email yesterday was a > relief. > > I just introduced myself to SOAP a couple days ago, and I must say > that I like suds and it's interface much more than the other libraries > I tried (SOAPpy and ZSI). FYI, SOAPpy seems to have the same > namespace problems (I didn't fully test ZSI). > > Keep up the good work guys! > > Gary > > [1] > https://www.redhat.com/archives/fedora-suds-list/2008-May/msg00013.html > > _______________________________________________ > fedora-suds-list mailing list > fedora-suds-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-suds-list From jortel at redhat.com Wed May 21 12:27:04 2008 From: jortel at redhat.com (Jeff Ortel) Date: Wed, 21 May 2008 08:27:04 -0400 Subject: [Fedora-suds-list] .NET Namespace Issue In-Reply-To: <4833A7D4.2080606@gmail.com> References: <48338460.7010903@gmail.com> <48339612.5090806@gmail.com> <4833A7D4.2080606@gmail.com> Message-ID: <48341518.5080304@redhat.com> Rob, Yes, Gary is right. FYI: By using the xmlns="" notation instead of the prefix you're qualifying the entire fragment as being in the (http://www.perseus.com/Pdc.WS) namespace instead of just the node. I'd have to see the entire wsdl to be sure but this looks like the issue described by ticket #7. Besides all of the cases involving the elementFormDefault involve Microsoft services so it's pretty likely ;-) I'm concerned about you comment that you had a problem using trunk. I committed code last night 7pm EDT that included the fix for ticket #7 and a LOT of other changes. All my regression tests were clean but, every wsdl is different ... When did you try trunk? Can you send me link/copy of the wsdl so I test against it? Thanks, Jeff Rob Yates wrote: > Gary - Thanks for the reply, good information. I have had no better > luck in ZSI or SOAPpy with this particular web service either. > -Rob > > Gary Wilson Jr. wrote: >> Rob Yates wrote: >>> As I'm fairly namespace-challenged, any ideas why this may be >>> happening? Thanks in advance for any assistance. >>> I'd be happy to send the WSDL via e-mail to whoever may want to take >>> a look. >> >> I'm having the same problem as you :) and I believe this is the issue: >> >> https://fedorahosted.org/suds/ticket/7 >> >> Jeff Ortel mentioned in an email to the list yesterday [1] that he has >> fixed the issue in his development code and that it will be put in >> trunk after some testing. The relevant snippet of that email: >> >> ------ >> * (fix) Proper level of XML element qualification based on > elementFormDefault=""/> attribute. This will ensure that when >> elementFormDefault="qualified", Suds will include the proper namespace >> on root elements for both literal and encoded bindings. In order for >> this to work properly, the literal marshaller (like the encoded >> marshaller) needed to be schema-type aware. Had i added the same >> schema-type lookup as the encoded marshaller instead of the >> refactoring described above, the two classes would have been almost a >> complete duplicate of each other :-( >> ------ >> >> I was building a fairly complex SOAP request the other day, and was >> going crazy trying to figure out why I was only getting a 500 error >> response back no matter what I tried. Jeff's email yesterday was a >> relief. >> >> I just introduced myself to SOAP a couple days ago, and I must say >> that I like suds and it's interface much more than the other libraries >> I tried (SOAPpy and ZSI). FYI, SOAPpy seems to have the same >> namespace problems (I didn't fully test ZSI). >> >> Keep up the good work guys! >> >> Gary >> >> [1] >> https://www.redhat.com/archives/fedora-suds-list/2008-May/msg00013.html >> >> _______________________________________________ >> fedora-suds-list mailing list >> fedora-suds-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-suds-list > > _______________________________________________ > fedora-suds-list mailing list > fedora-suds-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-suds-list -- Jeff Ortel RHN Satellite Engineering Centennial (324D) (P) 919-754-4603 From jortel at redhat.com Thu May 22 13:19:02 2008 From: jortel at redhat.com (Jeff Ortel) Date: Thu, 22 May 2008 09:19:02 -0400 Subject: [Fedora-suds-list] Trunk updated Message-ID: <483572C6.1080809@redhat.com> All, The changes, fixes and enhancements listed below have been committed to trunk as of r123. After further field testing (thanks Noehr at Coniuro), a few more patches were applied and trunk seems stable at r130. As described in the earlier email, this commit contains a number of changes. Some changes are simple code refactoring. Others, provide either performance enhancements (I found places where I was doing stupid things and corrected them), functionality enhancements or bug fixes. I would greatly appreciate any testing and feedback. So, what's the impact of Suds users? [ FIXES ] * sudsobject.Object no longer contains attributes that can hide wsdl defined object attributes. Although, if a wsdl defines an object with python built-in like attributes such as __dict__ or __factory__, then all bets are off. But, I have to make some assumptions and draw the line somewhere. * serviceproxy.ServiceProxy also no longer contains attributes that can hide service methods (operations). This is a little bit of a lie. I haven't removed the get_instance() and get_enum() methods *yet* because this will break everyones code. I've added the __factory__ and changed the README but haven't removed the methods but I intend to remove them in 0.2.2. Question: Would it be useful to have a function in the suds package that would return a service proxy and a factory? Like this? > > import suds > service, factory = suds.get_service('http://google.com/services/wsdl') > If anyone has a cleaner solution, please let me know. * The attribute elementFormDefault is being processed and if equals 'qualified', Suds will (according to my understanding of the specs) qualify all elements with a namespace. This will be useful when dealing with services provided by our friends in Redmond ;-) [ ENHANCEMENTS ] * The marshaller and unmarshaller classes have been refactored into a hierarchy where the base classes are provide basic conversion to/from XML. The subclasses layer on varying levels of type awareness. So, the marshaller.Basic class is schema-type unaware; the marshaller.Literal adds more awareness; and the marshaller.Encoded has the most schema-type awareness. This is the same for the unmarshallers. For outbound soap messages, only the Literal and Encoded marshallers are used. For inbound soap messages, both unmarshallers are used: Faults are processed by the unmarshaleller.Basic and returned values are processed by the unmarshaller.Typed object. WHAT THIS MEANS is that every (outbound) sudsobject.Object attribute and every (inbound) XML element is matched to a type defined in the wsdl (which includes xsi and soap built-in types). This lookup is very cheep because the Resolver classes used to resolve these types retain context so lookups are done by simply looking through a very small list of children and matching by name. Most users should never know the difference except for better precision and richer functionality now and down the road. * Better logging. During the refactoring, better logging statements were added. Is this too much detail? Regards, Jeff -------- Original Message -------- Subject: [Fedora-suds-list] development update Date: Mon, 19 May 2008 12:32:56 -0400 From: Jeff Ortel Organization: Platform Engineering To: fedora-suds-list at redhat.com All, I'd like to briefly update everyone on some of the things I'm currently working on: In order to support the new features and fix reported bugs, I'm in the process of refactoring and hopefully evolving the components in Suds that provide the input/output translations: * Builder ( translates: XSD objects => python objects ) * Marshaller ( translates: python objects => XML/SOAP ) * Unmarshaller ( translates: soap/xml => python objects ) This evolution will provide better symmetry between these components as follows: The Builder and Unmarshaller will produce python (subclass of sudsobject.Object) objects with: * __metadata__.__type__ = XSD type (SchemaProperty) * subclass name ( __class__.__name__ ) = schema-type name. and The Marshaller(s), while consuming python objects produced by the Builder or Unmarshaller, will leverage this standard information to produce the appropriate output ( XML/SOAP ). The 0.2.1 code behaves *mostly* like this but ... not quite. Also, the implementations have some redundancy. While doing this, it made sense to factor out the common schema-type "lookup" functionality used by the Builder, Marshallers and Unmarshaller classes into a hierarchy of "Resolver" classes. This reduces the complexity and redundancy of the Builder, Marshallers and Unmarshaller classes and allows for better modularity. Once this refactoring was complete, the difference between the literal/encoded Marshallers became very small. Given that the amount of code in the bindings.literal and bindings.encoded packages was small (and getting smaller) and in the interest of keeping the Suds code base compact, I moved all of the marshalling classes to the bindings.marshaller module. All of the bindings.XX sub-packages will be removed. The net effect: All of the Suds major components: * service proxy * wsdl * schema * resolvers * output (marshalling) * builder * input (unmarshalling) Now have better: * modularity * symmetry with regard to Object metadata. * code re-use (< 1% code duplication --- i hope) * looser coupling ... and better provide for the following features/bug-fixes: * (fix) Proper level of XML element qualification based on attribute. This will ensure that when elementFormDefault="qualified", Suds will include the proper namespace on root elements for both literal and encoded bindings. In order for this to work properly, the literal marshaller (like the encoded marshaller) needed to be schema-type aware. Had i added the same schema-type lookup as the encoded marshaller instead of the refactoring described above, the two classes would have been almost a complete duplicate of each other :-( * (enhancement) The builder and unmarshaller used the schema.Schema.find() to resolve schema-types. They constructed a path as "person.name.first" to resolve types in proper context. Since the Schema.find() was stateless, it resolved the intermediate path elements on every call. The new resolver classes are statefull and resolve child types *much* more efficiently. * (enhancement) Add a metadata flag so that marshaller will ouput innerXML as escaped TEXT content instead of child nodes. * (future-feature) have the marshaller/unmarshallers do python<=> xs type conversions such as xs:date, xs:datetime etc ..... Other fixes in my workspace waiting to be commited: * (fix/enhancement) Name collisions in sudsobject.Object like the items() method. I've moved all methods (including class methods) to a Factory class that is included in the Object class as a class attr ( __factory__ ). Now that *all* attributes have python built-in naming, we should not have any more name collisions. This of course assumes that no wsdl/schema entity names will have a name with the python built-in naming convention but I have to draw the line somewhere :-) I'm pretty jammed at work right now so my time to work on suds is limited. I have all of these changes and fixes coded and mostly tested. Once, completely regression tested, I'll release to trunk. If you're waiting on what seems like a simple fix to hit truck, it's probably been completed but because it's mixed in these larger changes, it's been delayed reaching trunk. Also, I'm going to try and get a public bugzilla site setup to track features and bugs. As the suds community get larger and larger, my ability to properly track these things (on top of my current work load) is getting stretched. I need the community to help me and access to a public facility such as bugzilla would really help. If you feel that your bug or feature request has "slipped through the cracks", I apologize. For now, please remind me on the list. Thanks to everyone for your interest and help with suds, Jeff _______________________________________________ fedora-suds-list mailing list fedora-suds-list at redhat.com https://www.redhat.com/mailman/listinfo/fedora-suds-list -- Jeff Ortel RHN Satellite Engineering Centennial (324D) (P) 919-754-4603 From jortel at redhat.com Fri May 23 21:17:35 2008 From: jortel at redhat.com (Jeff Ortel) Date: Fri, 23 May 2008 17:17:35 -0400 Subject: [Fedora-suds-list] suds news Message-ID: <4837346F.8070300@redhat.com> All, ITEM #1 ------------------------- background: Due to name collision problems I need to remove all non __xx__ attributes from the ServiceProxy and Object classes. The Object has been completely cleaned up and the ServiceProxy has been cleaned with the exception of get_instance() and get_enum(). They have been left as is for backwards compatibility. Although I later found out that removing the dict() in Object broke some user code. So, I need to find a home for this and other methods. For the ServiceProxy, the implementation of get_instance() and get_enum() we moved to a Factory class that is an attribute of the ServiceProxy as __factory__. The idea was the in the future (when get_instance() and get_enum() was deprecated) users would use the factory to create wsdl objects. However, having user access __factory__ was kind of "hacky" so .... news: I decided to introduce a 2nd generation API and leave the existing ServiceProxy as is. The concept is that instead of using the ServiceProxy, user would use the Suds Client instead. The client is an object that contains both a proxy for the service, a factory and other relevant objects that make up the client. The client would also contain other convenience methods and attributes such as the Object dict() method. This would work as follows (see README starting @ line 166): > > from client import Client > > # param is wsdl url and kwargs just like the SeviceProxy > client = Client('...') > > # factory.create() replaces ServiceProxy.get_instance() and get_enum() > person = client.factory.create('Person') > > # service method invocation - just like ServiceProxy > result = client.service.addPerson(person) > > # get a dictionary for the result (Object), replaces Object.dict() > mydict = client.dict(result) > Anyway, you get the idea. The client.py exists on trunk and has been tested. Pending comments and/or objections, I'll change the existing ServiceProxy implementation to use the new Client class under the covers to avoid code duplication sometime next week. We can leave the existing ServiceProxy for backwards compatibility for as long as the community wishes to leave it. Your comments please .... ITEM #2 I was looking at the Element specification within the XSD specification and noticed that Suds doesn't honor either the *form* attribute or the *nillable* attribute. I've added (and committed) support for both with the exception that pending the following question, I need replace the nil_supported keyword flag check in the marshaller(s) with checking the SchemaProperty.nillable attribute. Question: Since @nillable is now supported, do we still need the nil_supported keyword/flag? Can everyone using the nil_supported keyword with a value ( False ) please review you WSDLs and determine if this flag is still needed? I'm assuming that if these WSDLs contain ELEMENTS with nillable either (false) or not specified (the default is false), then Suds' new support of provide the same result as having the nil_supported flag (False). If this is true, when we can remove the nil_supported keyword. An easy way to try this on your WSDL is: Using the latest (r138+) code on trunk change marshaller.py line 119: from > if self.nil_supported: to: > if content.type.nillable An run against your services. Thanks, Jeff --- Jeff Ortel RHN Satellite Engineering Centennial (324D) (P) 919-754-4603