Issue Details (XML | Word | Printable)

Key: AXIS-2391
Type: Bug Bug
Status: Open Open
Priority: Blocker Blocker
Assignee: Unassigned
Reporter: Vaduz
Votes: 4
Watchers: 5
Operations

If you were logged in you would be able to see more operations.
Axis

WSDL2Java ignores attributes for complex types that have only element with maxOccurs=unbounded in sequence

Created: 02/Feb/06 02:23 AM   Updated: 04/May/07 12:36 PM
Return to search
Component/s: WSDL processing
Affects Version/s: 1.3
Fix Version/s: None

Time Tracking:
Not Specified

File Attachments:
  Size
Zip Archive Licensed for inclusion in ASF works axis-2391.zip 2006-09-27 04:30 PM Nathan Lipke 4 kB
Environment:
Axis for Java v1.3

java version "1.5.0_01"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_01-b08)
Java HotSpot(TM) Client VM (build 1.5.0_01-b08, mixed mode, sharing)

Windows XP Professional, SP2


 Description  « Hide
WSDL2Java generates wrong source code for the complex type of the following structure:

<xs:complexType name="SomeListType">
<xs:sequence>
<xs:element name="Item" type="tns:ItemType" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="attr1" type="xs:string" />
<xs:attribute name="attr2" type="xs:string" />
</xs:complexType>

The complex type should be a sequence with only element, which has maxOccurs="unbounded".
In this case all atributes are ignored and not included to the resulting type.

Version 1.2 works correctly. Version 1.3 works correctly, if the sequense has includes more than one element.

The sample WSDL used for test:

--------------------------------------------------

<?xml version="1.0" encoding="UTF-8"?>

<definitions name ="DayOfWeek"
  targetNamespace="http://www/bug/DayOfWeek.wsdl"
  xmlns:tns="http://www/bug/DayOfWeek.wsdl"
  xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
  xmlns:xsd="http://www.w3.org/2001/XMLSchema"
  xmlns="http://schemas.xmlsoap.org/wsdl/">

<types>
<xsd:schema>
<xsd:complexType name="ReplyType">
<xsd:sequence>
<xsd:element name="Item" type="xsd:string" maxOccurs="unbounded"/>
</xsd:sequence>
<xsd:attribute name="attr1" type="xsd:string" />
<xsd:attribute name="attr2" type="xsd:string" />
</xsd:complexType>
</xsd:schema>
</types>

  <message name="DayOfWeekInput">
    <part name="date" type="xsd:date"/>
  </message>
  <message name="DayOfWeekResponse">
    <part name="dayOfWeek" type="tns:ReplyType"/>
  </message>

  <portType name="DayOfWeekPortType">
    <operation name="GetDayOfWeek">
      <input message="tns:DayOfWeekInput"/>
      <output message="tns:DayOfWeekResponse"/>
    </operation>
  </portType>

  <binding name="DayOfWeekBinding" type="tns:DayOfWeekPortType">
    <soap:binding style="document"
      transport="http://schemas.xmlsoap.org/soap/http"/>
    <operation name="GetDayOfWeek">
      <soap:operation soapAction="getdayofweek"/>
      <input>
        <soap:body use="encoded"
          namespace="http://www/bug"
          encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
      </input>
      <output>
        <soap:body use="encoded"
          namespace="http://www/bug"
            encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
      </output>
    </operation>
  </binding>

  <service name="DayOfWeekService" >
    <documentation>
      Returns the day-of-week name for a given date
    </documentation>
    <port name="DayOfWeekPort" binding="tns:DayOfWeekBinding">
      <soap:address location="http://www/dayofweek/DayOfWeek"/>
    </port>
  </service>

</definitions>

--------------------------------------------------


For this WSDL Axis 1.2 generates the correct code:
...
public www.bug.DayOfWeek_wsdl.ReplyType getDayOfWeek(java.util.Date date) ...
...

Where reply type includes attributes attr1 and attr2 as well as Item array.

Axis 1.3 does not generate ReplyType class at all, and declares getDayOfWeek as following:

public java.lang.String[] getDayOfWeek(java.util.Date date)...

which is obviosly wrong.



 


 All   Comments   Work Log   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Jim Redman added a comment - 15/Feb/06 07:37 AM
I think that this is the same bug in a slightly different incarnation:

eg browse from http://opcfoundation.org/webservices/XMLDA/1.0/
generates this:

 public BrowseResponse browse(javax.xml.namespace.QName[] parameters) throws RemoteException {

which is missing the attributes. Without a fix or workaround, I'd also like to suggest that this bug gets promoted to critical since no progress can be made without a fix.

In the same WSDL it seems that "SubscriptionPolledRefresh" also misgenerates code.

<s:element name="Browse">
-
<s:complexType>
-
<s:sequence>
<s:element minOccurs="0" maxOccurs="unbounded" name="PropertyNames" type="s:QName"/>
</s:sequence>
<s:attribute name="LocaleID" type="s:string"/>
<s:attribute name="ClientRequestHandle" type="s:string"/>
<s:attribute name="ItemPath" type="s:string"/>
<s:attribute name="ItemName" type="s:string"/>
<s:attribute name="ContinuationPoint" type="s:string"/>
<s:attribute default="0" name="MaxElementsReturned" type="s:int"/>
<s:attribute default="all" name="BrowseFilter" type="s0:browseFilter"/>
<s:attribute name="ElementNameFilter" type="s:string"/>
<s:attribute name="VendorFilter" type="s:string"/>
<s:attribute default="false" name="ReturnAllProperties" type="s:boolean"/>
<s:attribute default="false" name="ReturnPropertyValues" type="s:boolean"/>
<s:attribute default="false" name="ReturnErrorText" type="s:boolean"/>
</s:complexType>
</s:element>

Jim Redman added a comment - 17/Feb/06 10:40 AM
I'd really like the priority promoted to "Blocker" since this kills any progress for us on a project. Who can do that to this bug? If me, how? If we can't do it to this bug, should I duplicate the bug with that priority? I'd hate to have to do that, but this is something of a killer bug, and since the interface (http://opcfoundation.org/webservices/XMLDA/1.0/) in question fails in 1.1, 1.2 and Axis2, without a bug fix or workaround, we're totoally blocked. Thanks.

Dies Koper added a comment - 17/Feb/06 11:44 AM
I think there is a bug in the code that determines whether arrays should be wrapped or not (see --wrapArrays option). It seems to ignore your attributes. I think setting the WSDL2Java option --wrapArrays should solve your problem. Please comment here if it works.

Jim Redman added a comment - 17/Feb/06 01:04 PM
From a quick first attempt, this looks as though it may be a valid work around. I'll build up the server-side code and check it more thoroughly.

Tom Jordahl added a comment - 18/Feb/06 03:33 AM
Upgrading to a blocker as requested.

Note that you may have to provide the fix for this yourself, as this priority doesn't imply that someone is working on it.

Tom Jordahl made changes - 18/Feb/06 03:33 AM
Field Original Value New Value
Priority Major [ 3 ] Blocker [ 1 ]
Karen Lease added a comment - 21/Feb/06 06:57 AM
I've also got this problem. I only had one attribute and I worked around it by using an extra element instead of the attribute.

Jim Redman added a comment - 21/Feb/06 09:04 AM
Karen: In this case, the WSDL interface is defined by a third party, so I don't have the luxury of changing it.
Tom: Thanks, and yes I realize that there's no promises that any bug will be fixed, but I figure that upping the priority can't hurt. My personal hope is that someone will recognise that this interface has caused, and is continuing to cause, problems with every release of Axis and that it will become a test interface, thereby improving the quality of Axis for all users. --wrapArrays is also looking hopeful as a work-around.

Jim Redman added a comment - 01/Mar/06 06:25 AM
As far as I can tell the work around, that is using -w on the WSDL2Java command line is a satisfactory work around for this issue in my case.

Unfortunately, I still can't proceed to fully test because 2222 is still a problem:

https://issues.apache.org/jira/browse/AXIS-2222

With a work around, we could drop the priority of this bug to something less than blocker. Could someone please boost 2222 to blocker (I realize that in principle this has no effect, but it does make me feel that at least the days spend on Axis are not completely wasted). Thanks.

Nathan Lipke added a comment - 27/Sep/06 04:30 PM
Patch to fix this bug.

I noticed this is still broken in Axis 1.4.

Also, this bug causes bad type generation for WSRP 2.0 schema:
http://www.oasis-open.org/apps/org/workgroup/wsrp/download.php/20061/wsrp_v2_types.xsd

Nathan Lipke made changes - 27/Sep/06 04:30 PM
Attachment axis-2391.zip [ 12341812 ]
Sören-Helge Zaschke added a comment - 04/May/07 12:36 PM
It looks like the same bug as I have observed:
AXIS can not handle the following type definition:
<xsd:complexType name="SomeName">
<xsd:sequence>
<xsd:element name="N1" type="Type1" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
<xsd:attribute name="N2" type="Type2" use="required"/>
</xsd:complexType>

Fix 1:
Change the xsd by adding another element (that is not used), e.g.
<xsd:complexType name="SomeName">
<xsd:sequence>
<xsd:element name="N1" type="Type1" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element name="N2" type="Type2" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
<xsd:attribute name="N2" type="Type2" use="required"/>
</xsd:complexType>

Fix 2:
Correct the AXIS source code, SchemaUtils.java:
------------------------------------------------------------
    public static QName getCollectionComponentQName(Node node,
                                                    QNameHolder itemQName,
                                                    BooleanHolder forElement,
                                                    SymbolTable symbolTable) {
        // If we're going to turn "wrapped" arrays into types such that
...
            }
            if (element == null) {
                return null;
            }
            
            // OK, exactly one element child of <sequence>,
            // now check if there is no attribute
            if (SchemaUtils.getChildByName(node, "attribute") != null) {
                return null;
            }

            // continue the processing using that element ...
------------------------------------------------------------