[ http://issues.apache.org/jira/browse/AXISCPP-24?page=all ] Fred Preston closed AXISCPP-24: -------------------------------
> enhancement: AxisC++ support for wrapped doc/lit > ------------------------------------------------ > > Key: AXISCPP-24 > URL: http://issues.apache.org/jira/browse/AXISCPP-24 > Project: Axis-C++ > Type: Bug > Components: Basic Architecture > Versions: Alpha > Environment: Operating System: Other > Platform: Other > Reporter: Sam Lang > Fix For: current (nightly) > > 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. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
