[
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
