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 ------- Additional Comments From [EMAIL PROTECTED] 2003-07-30 18:55 ------- I've got a patch that fixes this bug, partly. I'd appreciate some feedback before I commit it, however, as I think more work is needed to get this right. I've added a method to SchemaUtils that looks a lot like getComplexElementExtensionBase, except that it's called getComplexElementRestrictionBase. As the delta suggests, this method figures out what the base type is for a type that is derived-by-restriction. In JavaTypeWriter, I've added code to invoke this method iff the search for a base type through extension comes up empty. This causes the derived type to be written out as a subclass of the base type. I've modified getContainedElementDeclarations in SchemaUtils so that the search for the content model of a type will look inside of a restriction node, just as it currently does an extension node. This enables JavaTypeWriter to find the content model of the restricted subtype and so write out the appropriate accessors and ivars. Potential (probable) issue: The code in JavaTypeWriter that writes out ivars and accessor/mutator pairs does not currently check to see if those same ivars/methods are defined in the superclass of the type being written. This is not an issue for derivation-by-extension of complex types, as in that case the subtype is adding new fields/methods in addition to those on the super class. (you might think of this as derivation by addition, since "extension" is confusing when mixing the java/schema senses of the term). The derived type does not restate the content model of the parent type -- it simply 'adds' to it. This *is* an issue for derivation-by-restriction, however. In that case, the derived type is required to redeclare its entire content model, including the particles that belong to the super class. In practice, this means that the "elements" Vector that JavaTypeWriter works on contains *all* of the elements for the type, including those which are "inherited" from the base type. Hence the generated source code for the derived type ends up redeclaring all of the instance variables and member methods from the parent class(es). Since those instance variables are private and since the member methods do nothing but get/set their values, this is mostly harmless. However, it does waste memory if you have something like this: class ParentType { private String member; private String otherMember; public void setMember(String m) { this.member = m; } public String getMember() { return this.member; } public void setOtherMember(String m) { this.otherMember= m; } public String getOtherMember() { return this.otherMember; } } class DerivedType extends ParentType { private String member; // duplicate declaration, masks parent ivar public void setMember(String m) { this.member = m; } // duplicate public String getMember() { return this.member; } // duplicate } So, one todo here would be for JavaTypeWriter to avoid writing out ivars/methods for elements that are already present in the parent class. A more serious problem arises from the assumptions made in the encoding framework. Currently, that code uses the JavaBeans Introspector to get PropertyDescriptors for *all* properties in a class' inheritance hierarchy. Since derivation-by-restriction is intended to allow subtypes to *delete* elements from the content model of the supertype, this is not OK. It would cause the serializer/deserializer to look at (and read in/write out) fields that must not be included in the restricted type. Hence, a second todo is to modify TypeDesc so that it doesn't assume that it should handle every property in the inheritance hierarchy. I think the right thing to do here is to make type descs of restricted subtypes *not* include supertypes in their search for marshalable fields. However, we should continue to do a full hierarchy search with the JavaBeans Introspector for properties, as todo #1 will, if done correctly, cause some of the desirable fields/methods to live in the parent classes. In sum, the TypeDesc in the derived class will need to provide a complete list of allowed fields for that derivation, and the implementation of that typedesc will need to exclude superclass's from its view. IMHO, this approach is the most consistent with the way derivation-by- extension works in schema. Comments eagerly awaited
