axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Fred Preston (JIRA)" <>
Subject [jira] Closed: (AXISCPP-24) enhancement: AxisC++ support for wrapped doc/lit
Date Wed, 05 Apr 2006 13:04:51 GMT
     [ ]
Fred Preston closed AXISCPP-24:

> enhancement: AxisC++ support for wrapped doc/lit
> ------------------------------------------------
>          Key: AXISCPP-24
>          URL:
>      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:
For more information on JIRA, see:

View raw message