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

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