You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@axis.apache.org by "Henrik Nordberg (JIRA)" <ax...@ws.apache.org> on 2005/06/30 19:13:58 UTC
[jira] Created: (AXISCPP-720) Returning Array of complex type is broken
Returning Array of complex type is broken
-----------------------------------------
Key: AXISCPP-720
URL: http://issues.apache.org/jira/browse/AXISCPP-720
Project: Axis-C++
Type: Bug
Components: Serialization, WSDL processing - Doc
Versions: current (nightly)
Environment: Windows & Linux
Reporter: Henrik Nordberg
There is a problem with the way arrays of complex types are being serialized before they are returned to the client from the web service. The problem went away when returned an object that contained the array (different classes where then generated for the array, see below). I think the problem is the way the stubs are generated for the case when a complex array is retured directly and not as part of a class.
First I had the following interface on which I ran Java2WSDL and then WSDL2WS:
public interface DatabaseInfoProvider {
WsDatabaseObject[] getDatabaseObjects(String sUser, String sPassword, String connect, String objectTypes[], String searchString);
}
where
public class WsDatabaseObject {
public String sObjectType; // TABLE, VIEW, SP, SYNONYM
public String sObjectName;
public WsDatabaseColumn[] Columns;
}
where
public class WsDatabaseColumn {
public String name;
public Boolean isPrimaryKey;
}
Here is the important part:
The generated code for the array looks like:
typedef struct WsDatabaseObject_ArrayTag
{
WsDatabaseObject** m_Array; // <-- BUG MAY BE HERE
int m_Size;
} WsDatabaseObject_Array;
Then I change the interface to:
public interface DatabaseInfoProvider {
WsDatabaseInfo getDatabaseObjects(String sUser, String sPassword, String connect, String objectTypes[], String searchString);
}
where
public class WsDatabaseInfo {
public WsDatabaseObject[] dbInfo;
}
Note that the only difference is that I now return a class containing the array, instead of returning the array itself as was the case above.
The code for the array now looks like:
typedef struct WsDatabaseObject_ArrayTag
{
WsDatabaseObject* m_Array; // NOTE: just one * used
int m_Size;
} WsDatabaseObject_Array;
The same thing is true for the nested array ( public WsDatabaseColumn[] Columns; ). I.e., in the code generated by from the first version of the interface defined in Java, WsDatabaseColumn_ArrayTag has WsDatabaseColumn** m_Array;, but in the second version it has WsDatabaseColumn* m_Array;.
The first version crashes when serializing the result to be sent back to the client. The engine code seems to assume that the arrays are defined as T* m_Array and not T** m_Array.
--
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
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (AXISCPP-720) Returning Array of complex type is broken
Posted by "John Hawkins (JIRA)" <ax...@ws.apache.org>.
[ http://issues.apache.org/jira/browse/AXISCPP-720?page=comments#action_12359606 ]
John Hawkins commented on AXISCPP-720:
--------------------------------------
The coding of arrays has fundamentally changed. Can you try out with a new build?
> Returning Array of complex type is broken
> -----------------------------------------
>
> Key: AXISCPP-720
> URL: http://issues.apache.org/jira/browse/AXISCPP-720
> Project: Axis-C++
> Type: Bug
> Components: Serialization, WSDL processing - Doc
> Versions: current (nightly)
> Environment: Windows & Linux
> Reporter: Henrik Nordberg
> Attachments: konga_database_infoprovider.1.2.wsdl, konga_database_infoprovider.wsdl
>
> There is a problem with the way arrays of complex types are being serialized before they are returned to the client from the web service. The problem went away when returned an object that contained the array (different classes where then generated for the array, see below). I think the problem is the way the stubs are generated for the case when a complex array is retured directly and not as part of a class.
> First I had the following interface on which I ran Java2WSDL and then WSDL2WS:
> public interface DatabaseInfoProvider {
> WsDatabaseObject[] getDatabaseObjects(String sUser, String sPassword, String connect, String objectTypes[], String searchString);
> }
> where
> public class WsDatabaseObject {
> public String sObjectType; // TABLE, VIEW, SP, SYNONYM
> public String sObjectName;
> public WsDatabaseColumn[] Columns;
> }
> where
> public class WsDatabaseColumn {
> public String name;
> public Boolean isPrimaryKey;
> }
> Here is the important part:
> The generated code for the array looks like:
> typedef struct WsDatabaseObject_ArrayTag
> {
> WsDatabaseObject** m_Array; // <-- BUG MAY BE HERE
> int m_Size;
> } WsDatabaseObject_Array;
> Then I change the interface to:
> public interface DatabaseInfoProvider {
> WsDatabaseInfo getDatabaseObjects(String sUser, String sPassword, String connect, String objectTypes[], String searchString);
> }
> where
> public class WsDatabaseInfo {
> public WsDatabaseObject[] dbInfo;
> }
> Note that the only difference is that I now return a class containing the array, instead of returning the array itself as was the case above.
> The code for the array now looks like:
> typedef struct WsDatabaseObject_ArrayTag
> {
> WsDatabaseObject* m_Array; // NOTE: just one * used
> int m_Size;
> } WsDatabaseObject_Array;
> The same thing is true for the nested array ( public WsDatabaseColumn[] Columns; ). I.e., in the code generated by from the first version of the interface defined in Java, WsDatabaseColumn_ArrayTag has WsDatabaseColumn** m_Array;, but in the second version it has WsDatabaseColumn* m_Array;.
> The first version crashes when serializing the result to be sent back to the client. The engine code seems to assume that the arrays are defined as T* m_Array and not T** m_Array.
--
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
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (AXISCPP-720) Returning Array of complex type is broken
Posted by "Henrik Nordberg (JIRA)" <ax...@ws.apache.org>.
[ http://issues.apache.org/jira/browse/AXISCPP-720?page=comments#action_12360614 ]
Henrik Nordberg commented on AXISCPP-720:
-----------------------------------------
This bug seems to have been fixed and can be closed.
But I think the destructor of the generated array class needs to be virtual.
> Returning Array of complex type is broken
> -----------------------------------------
>
> Key: AXISCPP-720
> URL: http://issues.apache.org/jira/browse/AXISCPP-720
> Project: Axis-C++
> Type: Bug
> Components: Serialization, WSDL processing - Doc
> Versions: current (nightly)
> Environment: Windows & Linux
> Reporter: Henrik Nordberg
> Attachments: konga_database_infoprovider.1.2.wsdl, konga_database_infoprovider.wsdl
>
> There is a problem with the way arrays of complex types are being serialized before they are returned to the client from the web service. The problem went away when returned an object that contained the array (different classes where then generated for the array, see below). I think the problem is the way the stubs are generated for the case when a complex array is retured directly and not as part of a class.
> First I had the following interface on which I ran Java2WSDL and then WSDL2WS:
> public interface DatabaseInfoProvider {
> WsDatabaseObject[] getDatabaseObjects(String sUser, String sPassword, String connect, String objectTypes[], String searchString);
> }
> where
> public class WsDatabaseObject {
> public String sObjectType; // TABLE, VIEW, SP, SYNONYM
> public String sObjectName;
> public WsDatabaseColumn[] Columns;
> }
> where
> public class WsDatabaseColumn {
> public String name;
> public Boolean isPrimaryKey;
> }
> Here is the important part:
> The generated code for the array looks like:
> typedef struct WsDatabaseObject_ArrayTag
> {
> WsDatabaseObject** m_Array; // <-- BUG MAY BE HERE
> int m_Size;
> } WsDatabaseObject_Array;
> Then I change the interface to:
> public interface DatabaseInfoProvider {
> WsDatabaseInfo getDatabaseObjects(String sUser, String sPassword, String connect, String objectTypes[], String searchString);
> }
> where
> public class WsDatabaseInfo {
> public WsDatabaseObject[] dbInfo;
> }
> Note that the only difference is that I now return a class containing the array, instead of returning the array itself as was the case above.
> The code for the array now looks like:
> typedef struct WsDatabaseObject_ArrayTag
> {
> WsDatabaseObject* m_Array; // NOTE: just one * used
> int m_Size;
> } WsDatabaseObject_Array;
> The same thing is true for the nested array ( public WsDatabaseColumn[] Columns; ). I.e., in the code generated by from the first version of the interface defined in Java, WsDatabaseColumn_ArrayTag has WsDatabaseColumn** m_Array;, but in the second version it has WsDatabaseColumn* m_Array;.
> The first version crashes when serializing the result to be sent back to the client. The engine code seems to assume that the arrays are defined as T* m_Array and not T** m_Array.
--
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
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (AXISCPP-720) Returning Array of complex type is broken
Posted by "Henrik Nordberg (JIRA)" <ax...@ws.apache.org>.
[ http://issues.apache.org/jira/browse/AXISCPP-720?page=comments#action_12360449 ]
Henrik Nordberg commented on AXISCPP-720:
-----------------------------------------
I see that the dtors are no longer virtual. What is the reason for this?
I am in the process of testing this now.
> Returning Array of complex type is broken
> -----------------------------------------
>
> Key: AXISCPP-720
> URL: http://issues.apache.org/jira/browse/AXISCPP-720
> Project: Axis-C++
> Type: Bug
> Components: Serialization, WSDL processing - Doc
> Versions: current (nightly)
> Environment: Windows & Linux
> Reporter: Henrik Nordberg
> Attachments: konga_database_infoprovider.1.2.wsdl, konga_database_infoprovider.wsdl
>
> There is a problem with the way arrays of complex types are being serialized before they are returned to the client from the web service. The problem went away when returned an object that contained the array (different classes where then generated for the array, see below). I think the problem is the way the stubs are generated for the case when a complex array is retured directly and not as part of a class.
> First I had the following interface on which I ran Java2WSDL and then WSDL2WS:
> public interface DatabaseInfoProvider {
> WsDatabaseObject[] getDatabaseObjects(String sUser, String sPassword, String connect, String objectTypes[], String searchString);
> }
> where
> public class WsDatabaseObject {
> public String sObjectType; // TABLE, VIEW, SP, SYNONYM
> public String sObjectName;
> public WsDatabaseColumn[] Columns;
> }
> where
> public class WsDatabaseColumn {
> public String name;
> public Boolean isPrimaryKey;
> }
> Here is the important part:
> The generated code for the array looks like:
> typedef struct WsDatabaseObject_ArrayTag
> {
> WsDatabaseObject** m_Array; // <-- BUG MAY BE HERE
> int m_Size;
> } WsDatabaseObject_Array;
> Then I change the interface to:
> public interface DatabaseInfoProvider {
> WsDatabaseInfo getDatabaseObjects(String sUser, String sPassword, String connect, String objectTypes[], String searchString);
> }
> where
> public class WsDatabaseInfo {
> public WsDatabaseObject[] dbInfo;
> }
> Note that the only difference is that I now return a class containing the array, instead of returning the array itself as was the case above.
> The code for the array now looks like:
> typedef struct WsDatabaseObject_ArrayTag
> {
> WsDatabaseObject* m_Array; // NOTE: just one * used
> int m_Size;
> } WsDatabaseObject_Array;
> The same thing is true for the nested array ( public WsDatabaseColumn[] Columns; ). I.e., in the code generated by from the first version of the interface defined in Java, WsDatabaseColumn_ArrayTag has WsDatabaseColumn** m_Array;, but in the second version it has WsDatabaseColumn* m_Array;.
> The first version crashes when serializing the result to be sent back to the client. The engine code seems to assume that the arrays are defined as T* m_Array and not T** m_Array.
--
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
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Closed: (AXISCPP-720) Returning Array of complex type is
broken
Posted by "Fred Preston (JIRA)" <ax...@ws.apache.org>.
[ http://issues.apache.org/jira/browse/AXISCPP-720?page=all ]
Fred Preston closed AXISCPP-720:
--------------------------------
> Returning Array of complex type is broken
> -----------------------------------------
>
> Key: AXISCPP-720
> URL: http://issues.apache.org/jira/browse/AXISCPP-720
> Project: Axis-C++
> Type: Bug
> Components: Serialization, WSDL processing - Doc
> Versions: current (nightly)
> Environment: Windows & Linux
> Reporter: Henrik Nordberg
> Fix For: current (nightly)
> Attachments: konga_database_infoprovider.1.2.wsdl, konga_database_infoprovider.wsdl
>
> There is a problem with the way arrays of complex types are being serialized before they are returned to the client from the web service. The problem went away when returned an object that contained the array (different classes where then generated for the array, see below). I think the problem is the way the stubs are generated for the case when a complex array is retured directly and not as part of a class.
> First I had the following interface on which I ran Java2WSDL and then WSDL2WS:
> public interface DatabaseInfoProvider {
> WsDatabaseObject[] getDatabaseObjects(String sUser, String sPassword, String connect, String objectTypes[], String searchString);
> }
> where
> public class WsDatabaseObject {
> public String sObjectType; // TABLE, VIEW, SP, SYNONYM
> public String sObjectName;
> public WsDatabaseColumn[] Columns;
> }
> where
> public class WsDatabaseColumn {
> public String name;
> public Boolean isPrimaryKey;
> }
> Here is the important part:
> The generated code for the array looks like:
> typedef struct WsDatabaseObject_ArrayTag
> {
> WsDatabaseObject** m_Array; // <-- BUG MAY BE HERE
> int m_Size;
> } WsDatabaseObject_Array;
> Then I change the interface to:
> public interface DatabaseInfoProvider {
> WsDatabaseInfo getDatabaseObjects(String sUser, String sPassword, String connect, String objectTypes[], String searchString);
> }
> where
> public class WsDatabaseInfo {
> public WsDatabaseObject[] dbInfo;
> }
> Note that the only difference is that I now return a class containing the array, instead of returning the array itself as was the case above.
> The code for the array now looks like:
> typedef struct WsDatabaseObject_ArrayTag
> {
> WsDatabaseObject* m_Array; // NOTE: just one * used
> int m_Size;
> } WsDatabaseObject_Array;
> The same thing is true for the nested array ( public WsDatabaseColumn[] Columns; ). I.e., in the code generated by from the first version of the interface defined in Java, WsDatabaseColumn_ArrayTag has WsDatabaseColumn** m_Array;, but in the second version it has WsDatabaseColumn* m_Array;.
> The first version crashes when serializing the result to be sent back to the client. The engine code seems to assume that the arrays are defined as T* m_Array and not T** m_Array.
--
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
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (AXISCPP-720) Returning Array of complex type is broken
Posted by "Dushshantha Chandradasa (JIRA)" <ax...@ws.apache.org>.
[ http://issues.apache.org/jira/browse/AXISCPP-720?page=comments#action_12314859 ]
Dushshantha Chandradasa commented on AXISCPP-720:
-------------------------------------------------
Hi Henrik ,
Could you please attach the wsdl file that you used to generate codes using WSDL2WS ?? Then i can look in to the issue.
> Returning Array of complex type is broken
> -----------------------------------------
>
> Key: AXISCPP-720
> URL: http://issues.apache.org/jira/browse/AXISCPP-720
> Project: Axis-C++
> Type: Bug
> Components: Serialization, WSDL processing - Doc
> Versions: current (nightly)
> Environment: Windows & Linux
> Reporter: Henrik Nordberg
>
> There is a problem with the way arrays of complex types are being serialized before they are returned to the client from the web service. The problem went away when returned an object that contained the array (different classes where then generated for the array, see below). I think the problem is the way the stubs are generated for the case when a complex array is retured directly and not as part of a class.
> First I had the following interface on which I ran Java2WSDL and then WSDL2WS:
> public interface DatabaseInfoProvider {
> WsDatabaseObject[] getDatabaseObjects(String sUser, String sPassword, String connect, String objectTypes[], String searchString);
> }
> where
> public class WsDatabaseObject {
> public String sObjectType; // TABLE, VIEW, SP, SYNONYM
> public String sObjectName;
> public WsDatabaseColumn[] Columns;
> }
> where
> public class WsDatabaseColumn {
> public String name;
> public Boolean isPrimaryKey;
> }
> Here is the important part:
> The generated code for the array looks like:
> typedef struct WsDatabaseObject_ArrayTag
> {
> WsDatabaseObject** m_Array; // <-- BUG MAY BE HERE
> int m_Size;
> } WsDatabaseObject_Array;
> Then I change the interface to:
> public interface DatabaseInfoProvider {
> WsDatabaseInfo getDatabaseObjects(String sUser, String sPassword, String connect, String objectTypes[], String searchString);
> }
> where
> public class WsDatabaseInfo {
> public WsDatabaseObject[] dbInfo;
> }
> Note that the only difference is that I now return a class containing the array, instead of returning the array itself as was the case above.
> The code for the array now looks like:
> typedef struct WsDatabaseObject_ArrayTag
> {
> WsDatabaseObject* m_Array; // NOTE: just one * used
> int m_Size;
> } WsDatabaseObject_Array;
> The same thing is true for the nested array ( public WsDatabaseColumn[] Columns; ). I.e., in the code generated by from the first version of the interface defined in Java, WsDatabaseColumn_ArrayTag has WsDatabaseColumn** m_Array;, but in the second version it has WsDatabaseColumn* m_Array;.
> The first version crashes when serializing the result to be sent back to the client. The engine code seems to assume that the arrays are defined as T* m_Array and not T** m_Array.
--
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
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (AXISCPP-720) Returning Array of complex type is broken
Posted by "Fred Preston (JIRA)" <ax...@ws.apache.org>.
[ http://issues.apache.org/jira/browse/AXISCPP-720?page=comments#action_12332003 ]
Fred Preston commented on AXISCPP-720:
--------------------------------------
Could the fixer of this JIRA either create a new or incorporate into an existing test a test that would create a for this function so that we do not regress?
> Returning Array of complex type is broken
> -----------------------------------------
>
> Key: AXISCPP-720
> URL: http://issues.apache.org/jira/browse/AXISCPP-720
> Project: Axis-C++
> Type: Bug
> Components: Serialization, WSDL processing - Doc
> Versions: current (nightly)
> Environment: Windows & Linux
> Reporter: Henrik Nordberg
> Attachments: konga_database_infoprovider.1.2.wsdl, konga_database_infoprovider.wsdl
>
> There is a problem with the way arrays of complex types are being serialized before they are returned to the client from the web service. The problem went away when returned an object that contained the array (different classes where then generated for the array, see below). I think the problem is the way the stubs are generated for the case when a complex array is retured directly and not as part of a class.
> First I had the following interface on which I ran Java2WSDL and then WSDL2WS:
> public interface DatabaseInfoProvider {
> WsDatabaseObject[] getDatabaseObjects(String sUser, String sPassword, String connect, String objectTypes[], String searchString);
> }
> where
> public class WsDatabaseObject {
> public String sObjectType; // TABLE, VIEW, SP, SYNONYM
> public String sObjectName;
> public WsDatabaseColumn[] Columns;
> }
> where
> public class WsDatabaseColumn {
> public String name;
> public Boolean isPrimaryKey;
> }
> Here is the important part:
> The generated code for the array looks like:
> typedef struct WsDatabaseObject_ArrayTag
> {
> WsDatabaseObject** m_Array; // <-- BUG MAY BE HERE
> int m_Size;
> } WsDatabaseObject_Array;
> Then I change the interface to:
> public interface DatabaseInfoProvider {
> WsDatabaseInfo getDatabaseObjects(String sUser, String sPassword, String connect, String objectTypes[], String searchString);
> }
> where
> public class WsDatabaseInfo {
> public WsDatabaseObject[] dbInfo;
> }
> Note that the only difference is that I now return a class containing the array, instead of returning the array itself as was the case above.
> The code for the array now looks like:
> typedef struct WsDatabaseObject_ArrayTag
> {
> WsDatabaseObject* m_Array; // NOTE: just one * used
> int m_Size;
> } WsDatabaseObject_Array;
> The same thing is true for the nested array ( public WsDatabaseColumn[] Columns; ). I.e., in the code generated by from the first version of the interface defined in Java, WsDatabaseColumn_ArrayTag has WsDatabaseColumn** m_Array;, but in the second version it has WsDatabaseColumn* m_Array;.
> The first version crashes when serializing the result to be sent back to the client. The engine code seems to assume that the arrays are defined as T* m_Array and not T** m_Array.
--
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
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (AXISCPP-720) Returning Array of complex type is broken
Posted by "Henrik Nordberg (JIRA)" <ax...@ws.apache.org>.
[ http://issues.apache.org/jira/browse/AXISCPP-720?page=all ]
Henrik Nordberg updated AXISCPP-720:
------------------------------------
Attachment: konga_database_infoprovider.wsdl
This is the newer file that works.
> Returning Array of complex type is broken
> -----------------------------------------
>
> Key: AXISCPP-720
> URL: http://issues.apache.org/jira/browse/AXISCPP-720
> Project: Axis-C++
> Type: Bug
> Components: Serialization, WSDL processing - Doc
> Versions: current (nightly)
> Environment: Windows & Linux
> Reporter: Henrik Nordberg
> Attachments: konga_database_infoprovider.1.2.wsdl, konga_database_infoprovider.wsdl
>
> There is a problem with the way arrays of complex types are being serialized before they are returned to the client from the web service. The problem went away when returned an object that contained the array (different classes where then generated for the array, see below). I think the problem is the way the stubs are generated for the case when a complex array is retured directly and not as part of a class.
> First I had the following interface on which I ran Java2WSDL and then WSDL2WS:
> public interface DatabaseInfoProvider {
> WsDatabaseObject[] getDatabaseObjects(String sUser, String sPassword, String connect, String objectTypes[], String searchString);
> }
> where
> public class WsDatabaseObject {
> public String sObjectType; // TABLE, VIEW, SP, SYNONYM
> public String sObjectName;
> public WsDatabaseColumn[] Columns;
> }
> where
> public class WsDatabaseColumn {
> public String name;
> public Boolean isPrimaryKey;
> }
> Here is the important part:
> The generated code for the array looks like:
> typedef struct WsDatabaseObject_ArrayTag
> {
> WsDatabaseObject** m_Array; // <-- BUG MAY BE HERE
> int m_Size;
> } WsDatabaseObject_Array;
> Then I change the interface to:
> public interface DatabaseInfoProvider {
> WsDatabaseInfo getDatabaseObjects(String sUser, String sPassword, String connect, String objectTypes[], String searchString);
> }
> where
> public class WsDatabaseInfo {
> public WsDatabaseObject[] dbInfo;
> }
> Note that the only difference is that I now return a class containing the array, instead of returning the array itself as was the case above.
> The code for the array now looks like:
> typedef struct WsDatabaseObject_ArrayTag
> {
> WsDatabaseObject* m_Array; // NOTE: just one * used
> int m_Size;
> } WsDatabaseObject_Array;
> The same thing is true for the nested array ( public WsDatabaseColumn[] Columns; ). I.e., in the code generated by from the first version of the interface defined in Java, WsDatabaseColumn_ArrayTag has WsDatabaseColumn** m_Array;, but in the second version it has WsDatabaseColumn* m_Array;.
> The first version crashes when serializing the result to be sent back to the client. The engine code seems to assume that the arrays are defined as T* m_Array and not T** m_Array.
--
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
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Resolved: (AXISCPP-720) Returning Array of complex type is broken
Posted by "Adrian Dick (JIRA)" <ax...@ws.apache.org>.
[ http://issues.apache.org/jira/browse/AXISCPP-720?page=all ]
Adrian Dick resolved AXISCPP-720:
---------------------------------
Fix Version: current (nightly)
Resolution: Fixed
I have corrected the destructors to be virtual. Can't remember why I didn't do that originally, but I've just tried re-running the test suite and there are no problems.
> Returning Array of complex type is broken
> -----------------------------------------
>
> Key: AXISCPP-720
> URL: http://issues.apache.org/jira/browse/AXISCPP-720
> Project: Axis-C++
> Type: Bug
> Components: Serialization, WSDL processing - Doc
> Versions: current (nightly)
> Environment: Windows & Linux
> Reporter: Henrik Nordberg
> Fix For: current (nightly)
> Attachments: konga_database_infoprovider.1.2.wsdl, konga_database_infoprovider.wsdl
>
> There is a problem with the way arrays of complex types are being serialized before they are returned to the client from the web service. The problem went away when returned an object that contained the array (different classes where then generated for the array, see below). I think the problem is the way the stubs are generated for the case when a complex array is retured directly and not as part of a class.
> First I had the following interface on which I ran Java2WSDL and then WSDL2WS:
> public interface DatabaseInfoProvider {
> WsDatabaseObject[] getDatabaseObjects(String sUser, String sPassword, String connect, String objectTypes[], String searchString);
> }
> where
> public class WsDatabaseObject {
> public String sObjectType; // TABLE, VIEW, SP, SYNONYM
> public String sObjectName;
> public WsDatabaseColumn[] Columns;
> }
> where
> public class WsDatabaseColumn {
> public String name;
> public Boolean isPrimaryKey;
> }
> Here is the important part:
> The generated code for the array looks like:
> typedef struct WsDatabaseObject_ArrayTag
> {
> WsDatabaseObject** m_Array; // <-- BUG MAY BE HERE
> int m_Size;
> } WsDatabaseObject_Array;
> Then I change the interface to:
> public interface DatabaseInfoProvider {
> WsDatabaseInfo getDatabaseObjects(String sUser, String sPassword, String connect, String objectTypes[], String searchString);
> }
> where
> public class WsDatabaseInfo {
> public WsDatabaseObject[] dbInfo;
> }
> Note that the only difference is that I now return a class containing the array, instead of returning the array itself as was the case above.
> The code for the array now looks like:
> typedef struct WsDatabaseObject_ArrayTag
> {
> WsDatabaseObject* m_Array; // NOTE: just one * used
> int m_Size;
> } WsDatabaseObject_Array;
> The same thing is true for the nested array ( public WsDatabaseColumn[] Columns; ). I.e., in the code generated by from the first version of the interface defined in Java, WsDatabaseColumn_ArrayTag has WsDatabaseColumn** m_Array;, but in the second version it has WsDatabaseColumn* m_Array;.
> The first version crashes when serializing the result to be sent back to the client. The engine code seems to assume that the arrays are defined as T* m_Array and not T** m_Array.
--
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
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (AXISCPP-720) Returning Array of complex type is broken
Posted by "Henrik Nordberg (JIRA)" <ax...@ws.apache.org>.
[ http://issues.apache.org/jira/browse/AXISCPP-720?page=all ]
Henrik Nordberg updated AXISCPP-720:
------------------------------------
Attachment: konga_database_infoprovider.1.2.wsdl
This is the older file that causes the broken code to be generated.
> Returning Array of complex type is broken
> -----------------------------------------
>
> Key: AXISCPP-720
> URL: http://issues.apache.org/jira/browse/AXISCPP-720
> Project: Axis-C++
> Type: Bug
> Components: Serialization, WSDL processing - Doc
> Versions: current (nightly)
> Environment: Windows & Linux
> Reporter: Henrik Nordberg
> Attachments: konga_database_infoprovider.1.2.wsdl, konga_database_infoprovider.wsdl
>
> There is a problem with the way arrays of complex types are being serialized before they are returned to the client from the web service. The problem went away when returned an object that contained the array (different classes where then generated for the array, see below). I think the problem is the way the stubs are generated for the case when a complex array is retured directly and not as part of a class.
> First I had the following interface on which I ran Java2WSDL and then WSDL2WS:
> public interface DatabaseInfoProvider {
> WsDatabaseObject[] getDatabaseObjects(String sUser, String sPassword, String connect, String objectTypes[], String searchString);
> }
> where
> public class WsDatabaseObject {
> public String sObjectType; // TABLE, VIEW, SP, SYNONYM
> public String sObjectName;
> public WsDatabaseColumn[] Columns;
> }
> where
> public class WsDatabaseColumn {
> public String name;
> public Boolean isPrimaryKey;
> }
> Here is the important part:
> The generated code for the array looks like:
> typedef struct WsDatabaseObject_ArrayTag
> {
> WsDatabaseObject** m_Array; // <-- BUG MAY BE HERE
> int m_Size;
> } WsDatabaseObject_Array;
> Then I change the interface to:
> public interface DatabaseInfoProvider {
> WsDatabaseInfo getDatabaseObjects(String sUser, String sPassword, String connect, String objectTypes[], String searchString);
> }
> where
> public class WsDatabaseInfo {
> public WsDatabaseObject[] dbInfo;
> }
> Note that the only difference is that I now return a class containing the array, instead of returning the array itself as was the case above.
> The code for the array now looks like:
> typedef struct WsDatabaseObject_ArrayTag
> {
> WsDatabaseObject* m_Array; // NOTE: just one * used
> int m_Size;
> } WsDatabaseObject_Array;
> The same thing is true for the nested array ( public WsDatabaseColumn[] Columns; ). I.e., in the code generated by from the first version of the interface defined in Java, WsDatabaseColumn_ArrayTag has WsDatabaseColumn** m_Array;, but in the second version it has WsDatabaseColumn* m_Array;.
> The first version crashes when serializing the result to be sent back to the client. The engine code seems to assume that the arrays are defined as T* m_Array and not T** m_Array.
--
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
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira