You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by bu...@apache.org on 2003/03/03 15:59:55 UTC

DO NOT REPLY [Bug 17596] New: - Multiple code generation problems ( wrong types generated, names with first cap, attribute referneces)

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=17596>.
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=17596

Multiple code generation problems ( wrong types generated, names with first cap, attribute referneces)

           Summary: Multiple code generation problems ( wrong types
                    generated, names with first cap, attribute referneces)
           Product: Axis
           Version: current (nightly)
          Platform: PC
        OS/Version: Windows NT/2K
            Status: NEW
          Severity: Normal
          Priority: Other
         Component: WSDL processing
        AssignedTo: axis-dev@ws.apache.org
        ReportedBy: msapozhnikov@axsone.com


I have multiple problems trying to generate client subs from wsdl file. I am
attaching all related files.

1.
For the global element definition (in AxsGlobals.xsd)

  <element name="DBMAP">
    <simpleType>
      <restriction base="string">
        <maxLength value="8"/>
      </restriction>
    </simpleType>
  </element>

DBMAP.java gets generated, but in the classes that reference this type
(UserResponseType.java and UserRequestType.java)

the field appears like
private com.axsone.axis.glob.DBMAPType1 DBMAP;

But making the type global 

  <element name="DBMAP" type="tns:DBMAP"/>
  
  <simpleType name="DBMAP">
    <restriction base="string">
      <maxLength value="8"/>
    </restriction>
  </simpleType>

fixes the problem.

But similar definitions for SYS_USER and GROUP_ID inside complex type does not
cause the problem:

          <element name="SYS_USER"  minOccurs="0">
            <simpleType>
              <restriction base="string">
                <maxLength value="3"/>
              </restriction>
            </simpleType>
          </element>
          <element name="GROUP_ID" minOccurs="0">
            <simpleType>
              <restriction base="string">
                <maxLength value="8"/>
              </restriction>
            </simpleType>
          </element>

2.
Problems with referencing attributes.


2a. For the types that reference global attribute (in AppGlobals.xsd), e.g.

  <attribute name="FAC">
    <simpleType>
      <restriction base="string">
        <enumeration value="P"/>
        <enumeration value="S"/>
        <enumeration value="H"/>
      </restriction>
    </simpleType>
  </attribute>
 
  <complexType name="NumericFieldType">
    <simpleContent>
      <extension base="decimal">
        <attribute ref="tns:FAC"/>
      </extension>
    </simpleContent>
  </complexType>

results in the code generated: 

public class NumericFieldType  implements java.io.Serializable,
org.apache.axis.encoding.SimpleType {
    private java.math.BigDecimal value;

    public NumericFieldType() {
    }
?
}

Note: there is no field for the attribute here.

The same true for other types with similar syntax (TextFieldType,
PanelFieldType, etc.). 

2b. For the similar type with restriction

  <complexType name="FunctionFieldType">
    <complexContent>
      <restriction base="anyType">
       <attribute ref="tns:FAC"/> 
      </restriction>
    </complexContent>
  </complexType>

FunctionFieldType class is just empty:

public class FunctionFieldType  implements java.io.Serializable {

    public FunctionFieldType() {
    }
?
}


If I change type definition to:

  <complexType name="FunctionFieldType">
    <complexContent>
      <restriction base="anyType">
        <attribute name="FAC">
          <simpleType>
            <restriction base="string">
              <enumeration value="P"/>
              <enumeration value="S"/>
              <enumeration value="H"/>
            </restriction>
          </simpleType>
        </attribute>        
      </restriction>
    </complexContent>
  </complexType>

again produces empty code.

If I further change definition to extension (which is probably not correct ? I
am not sure):


  <complexType name="FunctionFieldType">
    <simpleContent>
      <extension base="anyType">
        <attribute name="FAC">
          <simpleType>
            <restriction base="string">
              <enumeration value="P"/>
              <enumeration value="S"/>
              <enumeration value="H"/>
            </restriction>
          </simpleType>
        </attribute>        
      </extension>
    </simpleContent>
  </complexType>

I am getting

public class FunctionFieldType  implements java.io.Serializable,
org.apache.axis.encoding.SimpleType {
    private java.lang.Object value;
    private com.axsone.axis.glob.app.FACType2 FAC;  // attribute

    public FunctionFieldType() {
    }

    public FunctionFieldType(java.lang.Object value) {
        this.value = value;
    }

    // Simple Types must have a String constructor
    public FunctionFieldType(java.lang.String value) {
        this.value = new java.lang.Object(value);
    }
?
}

which does not compile:

	Error(23,36): constructor Object(java.lang.String) not found in class
java.lang.Object


2c. Similar snippet of code (this time here used extension, not restriction):

  
  <complexType name="TabShowType">
    <simpleContent>
      <extension base="string">
        <attribute name="Show">
          <simpleType>
            <restriction base="string">
              <enumeration value="Y"/>
              <enumeration value="N"/>
            </restriction>
          </simpleType>
        </attribute>
      </extension>
    </simpleContent>
  </complexType>

results in the right code for the attribute in the class, but with every run
WSDL2Java creates new types: ShowType1, ShowType2, ShowType3, etc. (There is
another definition for the Show attribute in ErrorMessageType, which produces
Show type, this is why here ShowTypeN gets generated) 

3.
Problem with element names that have first capital letter.

It looks like AXIS creates field names in the generated by WSDL2Java code
following Java standards with first lowercase letter (e.g. SessionID will be
transformed to sessionID). 
The XML name for this field is set to
  field.setXmlName(new javax.xml.namespace.QName("", "SessionId"));

(note: here namespace is set to ""),

but when this code in BeanDeserializer.java gets executed

     if (typeDesc != null) {      
          // Lookup the name appropriately (assuming an unqualified
          // name for SOAP encoding, using the namespace otherwise)
          String fieldName = typeDesc.getFieldNameForElement(elemQName,
                                                             isEncoded);
          propDesc = (BeanPropertyDescriptor)propertyMap.get(fieldName);
          fieldDesc = typeDesc.getFieldByName(fieldName);
      }

      if (propDesc == null) {
          // look for a field by this name.
          propDesc = (BeanPropertyDescriptor) propertyMap.get(localName);
      }

fieldName is null, because in the getFieldNameForElement method even though
elemQName's and field's local parts are equal, their namespaces are not
(elemQName has qualified namespace, field's namespace="").

First "if" statement normally does not work for me, but second "if" statement
usually catches this for all my other element names (which all capital), but
cannot do it for the localName="SessionID", because property map has
"sessionID", not "SessionID". This causes SAXException.

This only happens on fields with first capital letter. AXIS does not modify
field if it all caps.
Something is wrong here: name conversion, propertyMap, handling logic or whatever.

I didn't have this problem with 1.0. 
I am attaching sample request and response. Response is produced by our server
and satisfies both AXIS and .NET clients.

I am using latest nightly build as of Feb. 27 and JDK 1.3.

Sorry for combining all of this in one bug, but it all seems to be related and
all could be reproduced with the same set of WSDL/XSDs.

Thanks,
Mike