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