[jira] Updated: (AXIS-1612) Inconsistent code generation by WSDL2Java

[ax...@ws.apache.org]

The following issue has been updated:

    Updater: Dan Ciarniello (mailto:dciarniello@cityxpress.com)
       Date: Sun, 17 Oct 2004 1:21 PM
    Changes:
             Attachment changed to wsdl.zip
    ---------------------------------------------------------------------
For a full history of the issue, see:

  http://issues.apache.org/jira/browse/AXIS-1612?page=history

---------------------------------------------------------------------
View the issue:
  http://issues.apache.org/jira/browse/AXIS-1612

Here is an overview of the issue:
---------------------------------------------------------------------
        Key: AXIS-1612
    Summary: Inconsistent code generation by WSDL2Java
       Type: Bug

     Status: Unassigned
   Priority: Major

    Project: Axis
 Components: 
             WSDL processing
   Versions:
             1.2RC1

   Assignee: 
   Reporter: Dan Ciarniello

    Created: Sun, 17 Oct 2004 1:21 PM
    Updated: Sun, 17 Oct 2004 1:21 PM
Environment: Linux Fedora Core 2, java 1.4.2_04-b05

Description:
I am attaching 5 WSDL files that illustrate what I believe to be inconsistencies in how WSDL2Java generates server code.  A couple of them also expose a bug where required classes may not be generated.  These inconsistencies make it difficult for Web Services newbies like myself to come up to speed.

In all cases, WSDL2Java is called with these arguments:

-n -s -o src <wsdlFile>

AxisTest1.wsdl
==============

WSDL2Java works exactly as expected with the code compiling without problem.
The service interface generated is:

package com.dciarnie.external;

public interface AxisTest extends java.rmi.Remote
{
  public DCObjectType getObject(String parameter) 
      throws java.rmi.RemoteException;
}

AxisTest2.wsdl
==============

Here, I am attempting to add another operation, getSomething, that takes two string parameters and returns a DCObjectType.  The service interface generated is:

package com.dciarnie.external;

import javax.xml.rpc.holders.*;

public interface AxisTest
    extends java.rmi.Remote
{
  public DCObjectType getObject(String parameter) 
      throws java.rmi.RemoteException;

  public void getSomething(String getSomethingParam1, 
                           String getSomethingParam2,
                           CalendarHolder DCObjectTypeThedate,
                           IntHolder DCObjectTypeAvalue) 
      throws java.rmi.RemoteException;
}

The first issue here is that even though the getSomething response has been declared in exactly the same way as for getObject, the generated method returns void rather than DCObjectType and takes two Holder parameters.  I don't understand why the responses have been generated differently.

Worse yet, the DCObjectType class does not get generated so the code doesn't compile.

Axis3.wsdl
==========

Here I've changed getSomethingResponse from

<element name="getSomethingResponse" type="impl:DCObjectType"/>

to

<element name="getSomethingResponse">
  <complexType>
    <sequence>
      <element name="getSomethingReturn" type="impl:DCObjectType"/>
    </sequence>
  </complexType>
</element>

This time the interface is:

package com.dciarnie.external;

public interface AxisTest extends java.rmi.Remote 
{
    public DCObjectType getObject(String parameter) 
        throws java.rmi.RemoteException;
    public DCObjectType getSomething(String getSomethingParam1, 
                                     String getSomethingParam2) 
        throws java.rmi.RemoteException;
}

That looks better.  The return types are the same.  However, the return types for getObject and getSomething have dissimilar declarations.  Also, DCObjectType still isn't generated.

Axis4.wsdl
==========

Now change getObjectResponse to look like getSomethingResponse in Axis3.wsdl. This gives:

package com.dciarnie.external;

public interface AxisTest
    extends java.rmi.Remote
{
  public _getObjectResponse getObject(String parameter) 
      throws java.rmi.RemoteException;

  public DCObjectType getSomething(String getSomethingParam1,
                                   String getSomethingParam2) 
      throws java.rmi.RemoteException;
}

This time getObject returns a _getObjectResponse object but the object isn't generated.  DCObject, however, now is!

Finally, 

Axis5.wsdl
==========

Here, I've changed

<element name="getObject" type="xsd:string"/>

to

<element name="getObject">
  <complexType>
    <sequence>
      <element name="param1" type="xsd:string"/>
    </sequence>
  </complexType>
</element>


package com.dciarnie.external;

public interface AxisTest
    extends java.rmi.Remote
{
  public DCObjectType getObject(String getObjectParam1) 
      throws java.rmi.RemoteException;

  public DCObjectType getSomething(String getSomethingParam1,
                                   String getSomethingParam2) 
      throws java.rmi.RemoteException;
}


I'm not sure why changing the way parameters to getObject are declared should affect the way the return is generated but here I finally have the signature that I expected from Axis2.wsdl and DCObjectType is generated.

Now, it makes sense to me that,

<element name="getObjectResponse" type="impl:DCObjectType"/>

should generate a method with a return of DCObjectType and that

<element name="getObjectResponse">
  <complexType>
    <sequence>
      <element name="getObjectReturn" type="impl:DCObjectType"/>
    </sequence>
  </complexType>
</element>

should generate a method with a return of getObjectResponse that encapsulates a DCObjectType.  I'm not sure that I would ever expect the version with Holders. WSDL2Java, however, generates all 4 possible combinations but in ways that are not obvious and that is confusing.



---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira