Details
-
Bug
-
Status: Closed
-
Resolution: Fixed
-
Alpha
-
None
-
Operating System: Other
Platform: Other
-
24807
Description
The AxisC++ deserializer still doesn't support wrapped doc/literal coding. The
parameter types are determined based on the xsi:type attribute, which isn't
required for serialized doc/lit encoded parameters. Because doc/lit is schema
driven, the parameter types are known by their element qnames, not by the
xsi:type attribute.
This presents a particular problem with the way Axis deserialization is done.
Currently what you're doing now is basically building your own DOM tree of the
parameters, where each element in the DOM tree contains info about its type
(leaf nodes contain their simple type info (xsi:type), while non-leaf nodes are
complex types). Because each of the elements contains the xsi:type attribute,
you are able to determine whether you've reached a leaf node (simple type) or
non-leaf node (anything that's not a simple type). This works well when the
soap style encoding is used, but not so well for doc/literal.
Also, even for soap encoding, the deserializer doesn't correctly check the
parameters as it deserializes them (I'm reporting a bug on this separately).
Since the xsi:type attributes are NOT included in the serialized xml for
doc/literal encoding, the only way to determine a parameter's type is to use the
schema. Because the schema defines structured types for each of the parameters
to an operation, the deserializer can know what types to expect (or at least,
what element qnames to expect, and what types those qnames map to). But the
qnames are defined in the schema, so the deserializer needs to be able to
deserialize a parameter using the qname/type information from the schema. Which
means somehow the Service Handler needs to be loaded before deserialization is
complete (right after the service name is found), and it needs to be able to
pass the type mapping info to the deserializer (XMLStreamHandler).
Specifically, the XMLStreamHandler::SetParamType function needs to be written to
support the ability to plugin a TypeMapping class from the Service Handler.
Also, the Service Handler code generated from the WSDL needs to also generate
the appropriate TypeMapping class for the types defined within the WSDL.
Attachments
Issue Links
- relates to
-
-
- Closed
-