[jira] Updated: (TUSCANY-826) Containment cycle should result in Exception

["Brian Murray (JIRA)" <tu...@ws.apache.org>]

     [ https://issues.apache.org/jira/browse/TUSCANY-826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Murray updated TUSCANY-826:
---------------------------------

    Attachment: ContainmentTest.zip
                ContainmentCycle.patch

Attaching ContainmentCycle.patch and ContainmentTest.zip.  The test case is included as a ZIP because it includes statically generated classes.  (The test case covers DataObjects whose types are defined using XSDHelper, TypeHelper, and XSD2JavaGenerator.)

The fix reflected in the patch is to pass the root DataObject (the DataObject identified by the user as the root for serialization) as a parameter to recursively encountered functions getXPath (for Java Serialization) and DataObjectXMLStreamReader (for XMLStreamHelper serialization) and to ensure that the root is not encountered a subsequent time while stepping through the DataObjects in the tree.  This technique does not introduce new loops, nor does it require synchronization.

If the root is encountered, then we know that a cycle exists.  (A cycle not including the root is not possible, because each DataObject can have only one container.)  When a cycle is encountered, the DataObject identified as the root by the user (the DO passed to the serialization method) is detached, breaking the cycle.

*****  This is a change to the actual structure of the DataObject tree, and not merely a characteristic of the serialized output.******
*******************************************************************************************************************************************
Please provide feedback on this behavioral change.  I recognize that it is a possible concern that calling a serialization method can affect the structure of the DataObject tree.

I feel that it is a safe behavior.  If a containment cycle exists, then it is clear that the tree is malformed and should be corrected.  Furthermore, we have allowed the user to specify which DataObject in the cycle should be viewed as the root.  (The DataObject which was passed to the serialization method.)

XMLHelper did not exhibit the StackOverflowException and in fact serialized the output just as Java and XMLStreamHelper serialization do following this change.  As such, XMLHelper has not been changed and does not exhibit the behavior of breaking the loop.  

Paul has correctly pointed out that Java serizliiation makes use of XMLHelper.save.  However, there is a StackOverflowException (and if that is caught, there is an IllegalStateException specific to the containment cycle) that results prior to the entry of XMLHelper.save.

> Containment cycle should result in Exception
> --------------------------------------------
>
>                 Key: TUSCANY-826
>                 URL: https://issues.apache.org/jira/browse/TUSCANY-826
>             Project: Tuscany
>          Issue Type: Bug
>          Components: Java SDO Implementation
>    Affects Versions: Java-SDO-Mx
>         Environment: Windows XP, both Sun and IBM JVMs
>            Reporter: Brian Murray
>             Fix For: Java-SDO-Mx
>
>         Attachments: ContainmentCycle.patch, ContainmentCycleError.java, ContainmentTest.zip
>
>
> Near the bottom of page 19 in the 2.0.1 specification it is stated that "Containment cannot have cycles.  If a set or add would create a containment cycle an exception is thrown."
> However, I have found that no such exception is thrown.  I will attach a test case showing the creation of (and the potential to infinitely loop through) a containment cycle.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org