suds May 2008

suds@lists.fedoraproject.org

7 participants
12 discussions

suds news
by Jeff Ortel 23 May '08

23 May '08

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 <element nillable=""/> 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

1 0

Trunk updated
by Jeff Ortel 22 May '08

22 May '08

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 <schema/> 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 <jortel(a)redhat.com> Organization: Platform Engineering To: fedora-suds-list(a)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 <schema 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 :-( * (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(a)redhat.com https://www.redhat.com/mailman/listinfo/fedora-suds-list -- Jeff Ortel RHN Satellite Engineering Centennial (324D) (P) 919-754-4603

1 0

.NET Namespace Issue
by Rob Yates 21 May '08

21 May '08

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: <SOAP-ENV:Envelope xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:tns="http://www.perseus.com/Pdc.WS" xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP-ENV:Body> <tns:Login> <userName>myUsername</userName> <password>myPassword</password> </tns:Login> </SOAP-ENV:Body> </SOAP-ENV:Envelope> 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: <SOAP-ENV:Envelope xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:tns="http://www.perseus.com/Pdc.WS" xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP-ENV:Body> <Login xmlns="http://www.perseus.com/Pdc.WS"> <userName>myUsername</userName> <password>myPassword</password> </Login> </SOAP-ENV:Body> </SOAP-ENV:Envelope> 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)

3 3

Suds Ticketing System
by Jeff Ortel 20 May '08

20 May '08

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

1 0

development update
by Jeff Ortel 19 May '08

19 May '08

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 <schema 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 :-( * (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

1 0

An error in wsdl parsing?
by Pablo Caro Revuelta 16 May '08

16 May '08

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 ): <?xml version="1.0" encoding="utf-8"?> <soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Body> <Logon xmlns="http://tempuri.org/"> <Username>string</Username> <Password>string</Password> </Logon> </soap:Body> </soap:Envelope> But the library send: <SOAP-ENV:Envelope 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/"> <SOAP-ENV:Body> <tns:Logon> <Username> <Username>user</Username> <Password>password</Password> </Username> </tns:Logon> </SOAP-ENV:Body> </SOAP-ENV:Envelope> 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(a)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.

3 5

Re: [Fedora-suds-list] Proposal to add .innerXML attribute to Object
by Tomasz Maćkowiak 16 May '08

16 May '08

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 <field id="5" innerXML="bar" /> but as <field id="5">bar</field> The contents of innerXML should be escaped. -- Z poważaniem / Best regards Tomasz Maćkowiak

1 0

Proposal to add .innerXML attribute to Object
by Jesper Nøhr 16 May '08

16 May '08

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

1 0

trunk patched (r122)
by Jeff Ortel 15 May '08

15 May '08

All, A patch has been applied to trunk (r122) to remove the strip() when processing (text) characters in the sax handler. Regards, Jeff

1 0

Unmarshaller problem?!
by Paulo Henrique Silva 15 May '08

15 May '08

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: <?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"><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> Here is the problem: Note that there are no spaces between version and encoding attributes on <?xml and later on Sesame namespace declaration 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: <?xml version="1.0" encoding="UTF-8"?><soapenv:Envelope 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:Body><ns1:sesameResponse soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:ns1="urn:Sesame"><return xsi:type="xsd:string"><?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">  <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> </return></ns1:sesameResponse></soapenv:Body></soapenv:Envelope> >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

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

suds May 2008