On Apr 27, 8:01 pm, "[EMAIL PROTECTED]"
<[EMAIL PROTECTED]> wrote:
> The test fails because the elements of an SDO list inside a complex
> type seem to be deleted when xmlrpc_encode_request is called on the
> SDO. There are no other references to the SDO, and the list is deleted
> when convert_to_array(sdo) is called by xmlrpc_encode_request. If the
> test retains another reference to the sdo, then it works fine. But I
> think the list should not get deleted. Here is a simple test which
> illustrates the problem, without using xmlrpc.
> The test creates an sdo which contains a list, and prints it before
> and after it is converted to an array. After the conversion, the field
> intArrayValue is empty. I would have expected to see an array with
> three integers.
> This can be fixed inside XMLRPC binding and the tests, but I think it
> should be fixed in the SDO implementation.
Rajini, you are right, there is a problem here. I'm not sure if it was
caused by a Tuscany change or simply exposed by my efforts to clear
out memory leaks of Tuscany DataObjects, probably the latter. The
problem is that Tuscany SDOLists are not reference-counted like
Tuscany SDODataObjects. So if, as in your example, you unset the only
reference to the DataObject, it disappears, taking the tree below with
it. If your $obj referred to a single-valued DataObject this would not
be a problem, because you're still holding a reference to it, but
holding a reference to the list doesn't make any difference.
I've checked in a fix to work round this for now, where the PHP
SDO_List holds a reference to the Tuscany SDOList's containing
DataObject as well as the list itself. This should fix the problem
you're seeing. I'll also start a dialogue with the Tuscany team about
how this is supposed to work.
You received this message because you are subscribed to the Google Groups
To post to this group, send email to email@example.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at