XFire
  1. XFire
  2. XFIRE-1110

Inheritance / Extensions in generated WSDL is not correct

    Details

    • Type: Bug Bug
    • Status: Open Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 1.2.6
    • Fix Version/s: None
    • Component/s: Aegis Module
    • Labels:
      None
    • Environment:
      Windows XP SP2, JBoss 4.2.2.GA, XFire 1.2.6
    • Patch Submitted:
      Yes
    • Number of attachments :
      1

      Description

      When accessing my WSDL, which is generated out of my JAVA classes on access, then the inheritance / extension are not set correctly.

      I debugged the XFire sources for a long time, and tried to find the place where this extension tag is set. I found the place in the "BeanType.java" in the method "writeSchema(Element)".
      There are several checks with the call "info.isExtension()". If this attribute in the BeanTypeInfo is set, the extension tag is written.
      BUT this attribute is not set correctly for ALL InfoTypes. I found a method called "getSuperType()" near the beginning of the "writeSchema(Element)" method. In this method the Superclass is checked, and if found one it is checked again for another Superclass AND then, on this superclass is set the isExtenstion attribute to true, when found another Superclass above the Superclass. But this works only for Superclasses, the normal types are not affected of this part.
      This is the reason why some extensions are set in the generated WSDL.

      I tried to find a good place, to add such a handling for all types and finally i set this in the constructor of the "BeanTypeInfo(Class, String)". So i set the isExtension attribute directly on the creation of the BeanTypeInfo. After this patch i got all extensions in my generated WSDL.

      Maybe this bug overlaps with one other inheritance bug here, but i don't find a bug especially for this issue.

      Additionally i don't know if this patch generates some ohter problems. Maybe another place for setting this attribute will be better, e.g. in the method "initializeProperties()" which is called in both constructors.

        Activity

        No changes have yet been made on this issue.

          People

          • Assignee:
            Dan Diephouse
            Reporter:
            Roland Burgermann
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated: