search

QUSIR / staff

Automatically exported from code.google.com/p/staff
Apache License 2.0
0 stars 0 forks source link

Soap request doesn't have child attributes for wsdl types with inheritance #191

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1.Generate a soap service from the wsdl on the file
2.Compile and run the code
3.Capture the request (soapUI, or wireshark)

What is the expected output? What do you see instead?
I'm setting the attributes for the base class and the derived class, but when 
the method is called it only sends the attributes from the base class in the 
request... 
(Note that this happens only if the method expects to receive an instance from 
the base class)

What version of the product are you using? On what operating system?
r711 on Ubuntu 11.10

Please provide any additional information below.

Original issue reported on code.google.com by alexmantaut on 21 Sep 2012 at 4:09

Attachments:

GoogleCodeExporter commented 9 years ago 
Child type is serialized as parent because reference to parent object(that goes 
from operation) is passed to serializing function.

I assume this is right behavior, because there is no method to detect what type 
comes on receiver's side.

When you need to serialize inherited types you should use 
dynamic(staff::Abstract) types.

Original comment by loentar on 22 Sep 2012 at 8:40

GoogleCodeExporter commented 9 years ago 
Ok, I'll use staff::Abstract

What shall I put  in the wsdl so staff creates the method with staff::Abstract 
types?

The wsdl I have right now is similiar to the one I've sent you, and I would 
like to only modify slightly wsdl (without making it incompatible with the 
previous syntax) or changing the parameters to staff_codegen.. (I would like to 
avoid as much as posible modifying the staff generated code, because of coding 
standard validation issues) is this posible?

Original comment by alexmantaut on 25 Sep 2012 at 2:01

GoogleCodeExporter commented 9 years ago 
Just add abstract="true" attribute to you base complexType like that:

http://www.w3.org/TR/2001/REC-xmlschema-0-20010502/#abstract

Original comment by loentar on 25 Sep 2012 at 5:52

GoogleCodeExporter commented 9 years ago 
I added the the abstract="true" to MyType1 (Base type) but the generated 
interface does not use staff::Abstract...
Actually by looking at my original wsdl it had abstract="true" for the base 
type, but it didn't serialized the base types... 
Is there anything else I should do in order to use staff::Abstract?

Original comment by alexmantaut on 25 Sep 2012 at 6:15

GoogleCodeExporter commented 9 years ago 
Please see example in attach.

This is a WSDL generated by abstract service example located at 
`staff/samples/abstract/component`.

Original comment by loentar on 25 Sep 2012 at 6:28

Attachments:

GoogleCodeExporter commented 9 years ago 
I've compared your wsdl to mine and I've managed to make the codegen use 
staff::Abstract, but still I have several issues.

On the example attached you can see that if createMyType1Request/Response uses 
an element the codegen sets the method to correctly use Abstract (foo.wsdl 
lines 56 to 71) but if I use the type1 directly it sets the method to use an 
instance of the base class (which should be Abstract instead)

Another problem arises with foo.wsdl lines 19 and 20... If I uncomment line 19 
and regenerate the code, the codegen issues a warning, and the created class 
doesn't have the attribute...

If I uncomment line 20 the codegen creates the code, but when I call method 
createMyType1() it crashes with segfault...

Am I doing something wrong in the wsdl?

Original comment by alexmantaut on 1 Oct 2012 at 3:36

Attachments:

GoogleCodeExporter commented 9 years ago 
Your wsdl looks right.

1. Type as message part: Accepted.

2. Codegen does right because "complexType" can't have "element" child, only 
under "sequence" element.

When I uncomment line with "attribute", generated request was right, but there 
is a bug while parsing response (Invalid response element name, when message 
part set as "type").

Also seems like there is a bug with SoapUI, it doesn't generate xsi:type 
attribute.

Original comment by loentar on 2 Oct 2012 at 2:05

GoogleCodeExporter commented 9 years ago

Original comment by loentar on 4 Oct 2012 at 7:48

GoogleCodeExporter commented 9 years ago 
This issue was closed by revision r715.

Original comment by loentar on 4 Oct 2012 at 8:02

GoogleCodeExporter commented 9 years ago 
Hi, I've tried the fix and it worked on the example I've originally sent you, 
but when I tried the original wsdl it still fails... It turns out that there is 
a bug if the type definition is in a separate xsd file...

If I generate the source files with :

staff_codegen -pwsdl -tclient_all inheritance_issue.wsdl

(wsdls attached to the comment)

the generated code doesn't use staff::Abstract, so I can't use it with 
inheritance.

I'm using r715

Original comment by alexmantaut on 12 Oct 2012 at 7:48

Attachments:

GoogleCodeExporter commented 9 years ago 
Sorry, didn't see last message earlier.

Now it should be fixed in r717.

Original comment by loentar on 6 Nov 2012 at 6:31