|
If you were logged in you would be able to see more operations.
|
|
|
|
Environment:
|
n/a
|
|
Issue Links:
|
dependent
|
|
This issue depends upon:
|
|
AXISCPP-148
AXIS-C tries to deserialize complex object which are nil
|
|
|
|
|
|
|
|
| Resolution Date: |
22/Dec/04 01:48 PM
|
|
Problem
=======
Assume that we have a 'nillable' DataType_Array that has been created from a WSDL as follows:-
DataType_Array.hpp
------------------
class DataType;
typedef struct DataType_ArrayTag
{
DataType * m_Array;
int m_Size;
} DataType_Array;
DataType.hpp
------------
class DataType
{
public:
xsd__int index;
xsd__string string;
};
In our implementation we have defined a variable array 'pDataType' of type DataType length 5.
Test.cpp
:
DataType * pDataType = new DataType[5];
:
Now, we want to populate indexes 2 and 3 with data, but leave the remaining array indexes (0, 1 and 4) empty (nill).
>>>>>Q1. How is this done?
NB: The serialised output should also look something like this...
<ns2:DataType>
<ns2:Item xsi:nil="true"/>
<ns2:Item>
<ns2:Item xsi:nil="true"/>
<ns2:Item>
<ns2:index>2</ns2:index>
<ns2:string>String index 2</ns2:string>
</ns2:Item>
<ns2:Item>
<ns2:index>3</ns2:index>
<ns2:string>String index 3</ns2:string>
</ns2:Item>
<ns2:Item xsi:nil="true"/>
<ns2:Item>
</ns2:DataType>
>>>>>Q2. How would the deserialiser cope?
|
|
Description
|
Problem
=======
Assume that we have a 'nillable' DataType_Array that has been created from a WSDL as follows:-
DataType_Array.hpp
------------------
class DataType;
typedef struct DataType_ArrayTag
{
DataType * m_Array;
int m_Size;
} DataType_Array;
DataType.hpp
------------
class DataType
{
public:
xsd__int index;
xsd__string string;
};
In our implementation we have defined a variable array 'pDataType' of type DataType length 5.
Test.cpp
:
DataType * pDataType = new DataType[5];
:
Now, we want to populate indexes 2 and 3 with data, but leave the remaining array indexes (0, 1 and 4) empty (nill).
>>>>>Q1. How is this done?
NB: The serialised output should also look something like this...
<ns2:DataType>
<ns2:Item xsi:nil="true"/>
<ns2:Item>
<ns2:Item xsi:nil="true"/>
<ns2:Item>
<ns2:index>2</ns2:index>
<ns2:string>String index 2</ns2:string>
</ns2:Item>
<ns2:Item>
<ns2:index>3</ns2:index>
<ns2:string>String index 3</ns2:string>
</ns2:Item>
<ns2:Item xsi:nil="true"/>
<ns2:Item>
</ns2:DataType>
>>>>>Q2. How would the deserialiser cope? |
Show » |
|
Bug
Blocker
much of work before end of Nov. (And it is even hard to emagine what the side effects would be)
Hence +1 for memsetting to 0 in case of nillable for the time being.
Do you think it is possible for us to take up Type1 **m_Array; style solution for 1.5? (Because
that is the most natual C++ solution)
Thanks,
Samisa...
--- Mark Whitlock <mark_whitlock@uk.ibm.com> wrote:
>
>
>
>
> Hi,
> For an array of complex types, the Axis C++ client can't set an array
> element to nil="true" in the soap message and it can't deserialize a soap
> message with one of the complex types nil. The same problem happens setting
> a complex type to nil when it is nested inside another complex type. For
> instance in the RecurseTypes testcase...
>
> <xsd:complexType name="Type1">
> <xsd:sequence>
> <xsd:element name="followings" maxOccurs="unbounded"
> minOccurs="0" type="tns:Type1" />
> <xsd:element name="index" type="xsd:int" />
> </xsd:sequence>
> </xsd:complexType>
>
> gets represented as...
>
> class Type1
> {
> public:
> Type1_Array followings;
> int index;
> Type1();
> ~Type1();
> };
>
> typedef struct Type1_ArrayTag
> {
> Type1* m_Array;
> int m_Size;
> } Type1_Array;
>
> So if the followings array has a length of 10, you always get 10 instances
> of Type1 within it. You can't set m_Array[3]=NULL because m_Array is an
> array of Type1, not an array of pointers to Type1. In the same way if the
> returned soap message says that the 3rd Type1 in the followings array
> should be nil, our deserializer can't cope. Of course Axis/Java doesn't
> have this problem since in Java, complex types are objects which are passed
> and embedded by address, so any object reference can be null.
>
> There doesn't seem to be any easy solution to this problem. I could change
> the way complex types are represented in C++ so that nested complex types
> have their address in the outer complex type or array. So in the above
> example Type1 **m_Array; or Type1* m_Array[];. This is a big change and I'm
> not proposing it. Or Axis C++ does not support nillable properly by never
> sending nil=true and if it is ever returned a soap message with nil=true in
> it, it creates an object (where there should be none) and memset's it to
> all zeroes.
>
> This problem is the subject of
AXISCPP-148andAXISCPP-260.> Does anybody have any comments on this?
> Mark
> Mark Whitlock
> IBM
>
>