axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject [jira] Resolved: (AXISCPP-24) enhancement: AxisC++ support for wrapped doc/lit
Date Wed, 07 Apr 2004 14:00:43 GMT

   The following issue has been resolved as FIXED.

   Resolver: Susantha Kumara
       Date: Wed, 7 Apr 2004 7:00 AM

This feature added in latest code
View the issue:

Here is an overview of the issue:
        Key: AXISCPP-24
    Summary: enhancement: AxisC++ support for wrapped doc/lit
       Type: Bug

     Status: Resolved
 Resolution: FIXED

    Project: Axis-C++
             Basic Architecture
   Fix Fors:
             current (nightly)

   Reporter: Sam Lang

    Created: Wed, 19 Nov 2003 7:29 AM
    Updated: Wed, 7 Apr 2004 7:00 AM
Environment: Operating System: Other
Platform: Other

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:

If you want more information on JIRA, or have a bug to report see:

View raw message