Bug 5358 - Stub generation issue with use of restriction base
: Stub generation issue with use of restriction base
Status: RESOLVED FIXED
: Java WS Core
globus_wsrf_core
: unspecified
: PC Windows XP
: P3 normal
: ---
Assigned To:
:
:
:
: 5327
  Show dependency treegraph
 
Reported: 2007-06-05 15:43 by
Modified: 2007-06-13 18:53 (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2007-06-05 15:43:14
Axis stub generation code does not generate a
QueryResouecePropertiesResponse.java, but maps this as a Java Object:

<xsd:element name="QueryResourcePropertiesResponse">
    <xsd:complexType>
      <xsd:complexContent mixed="true">
        <xsd:restriction base="xsd:anyType">
          <xsd:sequence>
            <xsd:any processContents="lax" 
                     minOccurs="1" maxOccurs="unbounded"/>
          </xsd:sequence>
        </xsd:restriction>
      </xsd:complexContent>
    </xsd:complexType>
  </xsd:element>
------- Comment #1 From 2007-06-13 18:53:35 -------
Could not identify if this mapping should be any different, since the JAX-RPC
specification does not mention anything about this. 

Committed a work around, where a stub for a datatype similar (without the
restriction piece) was hand generated and checked into source. There are other
files that seem to get copied from source into stubs/src and this file will
also get copied on stub generation. A typeMapping has been added for
wsrp:QueryResourcePropertiesResponse and it will get deserialized to
org.oasis.wsrf.properties.QueryResourcePropertiesResponse. Did not hand edit
the generated port type, so it has Object as response, but it can be type
casted to the above class. Tested with Query.java, the command line client and
seems to work okay. The wire message looks fine too.

There could be more elegant solutions or stub generation fix that needs to be
explored at some point.