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 ax...@ws.apache.org on 2004/10/17 22:21:51 UTC

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

Message:

  A new issue has been created in JIRA.

---------------------------------------------------------------------
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


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

Posted by "Jayachandra Sekhara Rao Sunkara (JIRA)" <ax...@ws.apache.org>.
     [ http://nagoya.apache.org/jira/browse/AXIS-1612?page=comments#action_54965 ]
     
Jayachandra Sekhara Rao Sunkara commented on AXIS-1612:
-------------------------------------------------------

As far as I tried to debug. I see that except for the first wsdl rest four wsdls are being treated as wrapped mode wsdls. I don't the reason. But the main problem why DCObjectType.java is not being created in the generateTypes() is that its type information has isOnlyLiteralReferenced being set to true. I haven't figured out the exact reason for this. A type for which code is to be generated must have isReferenced=ture and isOnlyLiteralReferenced=false. And this having failed in our case, we are unable to get DCObjectType.java generated. Any clarifications to some of the above unknown reasons will be of great help in resolving this issue.

Thank you,
Jayachandra

> Inconsistent code generation by WSDL2Java
> -----------------------------------------
>
>          Key: AXIS-1612
>          URL: http://nagoya.apache.org/jira/browse/AXIS-1612
>      Project: Axis
>         Type: Bug
>   Components: WSDL processing
>     Versions: 1.2RC1
>  Environment: Linux Fedora Core 2, java 1.4.2_04-b05
>     Reporter: Dan Ciarniello
>  Attachments: wsdl.zip
>
> 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.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://nagoya.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


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

Posted by 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