DO NOT REPLY [Bug 21981] New: - WSDL2Java fails to handle complexContent restrictions

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21981>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21981

WSDL2Java fails to handle complexContent restrictions

           Summary: WSDL2Java fails to handle complexContent restrictions
           Product: Axis
           Version: current (nightly)
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: Normal
          Priority: Other
         Component: WSDL processing
        AssignedTo: axis-dev@ws.apache.org
        ReportedBy: Eric.D.Friedman@wellsfargo.com


Given a schema type with a complexType whose content model is complexContent
with a restriction of some base type, WSDL2Java will emit a bean with NO members
at all.

This is because restrictions on *complex* types are not handled as some kind of
inheritance in the way that extensions are.  (That may well be correct, see
below).  Further, the code which gathers the
types-that-are-to-be-the-member-variables does not know how to traverse
restrictions as children of complexContent.  So, that code comes up empty when
it looks for sequences, choices, alls, and so on, resulting in a class with no
member variables.

I have a patch which I would like to commit that fixes this latter problem. 
Does anyone object to this solution?  Does anyone disagree with my hypothesis
that the current behavior -- do not interpret complex type
derivation-by-restriction as java inheritance -- is correct?

Some more justification for this hypothesis:  a type which derives from another
type by restriction must list all of the particles from its parent types in its
own content model.  Although it cannot remove required elements from the
parent's model, it *can* remove optional elements.  It is this last bit that
makes me leary of using inheritance -- it would be strange to have a class with
members Foo and Bar, and a subclass that may *not* have those members.  Would
you emit code that overrides the verboten methods from the parent and raise an
exception?  Probably not.

The trouble with the current behavior, of course, is that the type relation
between the base type and the restricted type is completely lost.  

Here's a simple example of some schema types that illustrate the issue:

<complexType name="MaleFemalePerson">
  <sequence>
     <element name="name" />
     <element name="weight" minOccurs="0" />
  </sequence>
   <attribute name="gender"/>
</complexType>

<complexType name="WeightlessHermaphrodite">
  <complexContent>
     <restriction base="MaleFemalePerson"> <!-- SchemaUtils can't hack this -->
       <sequence>
         <element name="name"> <!-- required in parent; must retain -->
        </sequence>
       <attribute name="gender" use="prohibited" />
      </restriction>
  </complexContent>
</complexType>


I am proposing that we generate this (roughly): 

class MaleFemalePerson {
  String name;
  int weight;
  String gender;
}

class WeightlessHermaphrodite { // "extends" MaleFemalePerson, sort of
  String name;
}

Currently we generate this, which is obviously broken:

class WeightlessHermaphrodite {
}