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

Frank Budinsky resolved TUSCANY-1565.
-------------------------------------

    Resolution: Invalid

Hi Chris,

This is working as expected. This line:

        person2.getList(addressProperty).add(address);

is adding to person2 the same address object from person1. Since it's a 
contained DataObject, SDO removes the object from it's old container (person1). 
See the last paragraph of section 3.1.6 in the spec 
(http://osoa.org/download/attachments/36/Java-SDO-Spec-v2.1.0-FINAL.pdf?version=1).

The exception you were seeing sounds like a generated code compatibility issue. 
Make sure you regenerate the classes with the version of SDO that you will run 
them with. If you do that and still see the problem (in the latest from HEAD - 
bug may have been fixed) please reopen the JIRA for it.

Thanks,
Frank.

> CopyHelper.copy() fails to copy schema extensions
> -------------------------------------------------
>
>                 Key: TUSCANY-1565
>                 URL: https://issues.apache.org/jira/browse/TUSCANY-1565
>             Project: Tuscany
>          Issue Type: Bug
>          Components: Java SDO Implementation
>    Affects Versions: Java-SDO-1.0
>         Environment: Win XP, IBM JRE 1.4.2 & IBM JRE 1.5.0
>            Reporter: Chris Mildebrandt
>         Attachments: Address.xsd, CopyTest.java, Person.xsd
>
>
> Hello,
> I've been seeing some weird behavior with the copy implementation. I have two 
> schemas, one with the following line:
> <xsd:any namespace="##other" processContents="lax" minOccurs="0" 
> maxOccurs="unbounded"/>
> I'm inserting the second schema into the first as a part of this extension. 
> When I run the CopyHelper.INSTANCE.copy() method against it, weird things 
> start to happen. 
> The first case:
> Both schema files are defined dynamically. The data objects are created and 
> one is added to the other. That looks like this:
>         HelperContext context = HelperProvider.getDefaultContext();
>         {
>             InputStream in = new File("Person.xsd").toURL().openStream();
>             context.getXSDHelper().define(in, null);
>         }
>         {
>             InputStream in = new File("Address.xsd").toURL().openStream();
>             context.getXSDHelper().define(in, null);
>         }
>         DataObject person1 = 
> context.getDataFactory().create("http://www.example.org/Person";, 
> "PersonType");
>         DataObject address = 
> context.getDataFactory().create("http://www.example.org/Address";, 
> "AddressType");
>         person1.set("Age", "30");
>         person1.set("Name", "Jim");
>         address.set("Street", "123 Fake St.");
>         address.set("City", "Springfield");
>         address.set("Zip", "46392");
>         Property addressProperty = 
> context.getXSDHelper().getGlobalProperty("http://www.example.org/Address";, 
> "Address", true);
>         (person1).getList(addressProperty).add(address);
>         
>         DataObject person2 = CopyHelper.INSTANCE.copy(person1);
>         
>         person2.getList(addressProperty).clear();
>         person2.getList(addressProperty).add(address);
> When I save the data objects to files, the person1 data object doesn't 
> contain the address data object, but person2 does. When I remove the last 
> line that adds the address to person2, then the person1 data object correctly 
> contains the address data object. I would think the person1 data object 
> shouldn't be affected by changes to the person2 (copy of person1) data object.
> The second case:
> Static classes are generated for the first schema, the second is defined 
> dynamically. Data objects are created for both, and the second is added to 
> the first. That looks like this:
>         HelperContext context = HelperProvider.getDefaultContext();
>         PersonFactory.INSTANCE.register(context);
>         PersonType person1 = PersonFactory.INSTANCE.createPersonType();
>         person1.setAge("30");
>         person1.setName("Jim");
>         InputStream in = new File("Address.xsd").toURL().openStream();
>         context.getXSDHelper().define(in, null);
>         DataObject address = 
> context.getDataFactory().create("http://www.example.org/Address";, 
> "AddressType");
>         address.set("Street", "123 Fake St.");
>         address.set("City", "Springfield");
>         address.set("Zip", "46392");
>         Property addressProperty = 
> context.getXSDHelper().getGlobalProperty("http://www.example.org/Address";, 
> "Address", true);
>         ((DataObject) person1).getList(addressProperty).add(address);
>         
>         PersonType person2 = (PersonType) 
> CopyHelper.INSTANCE.copy((DataObject) person1);
>         
>         ((DataObject) person2).getList(addressProperty).clear();
>         ((DataObject) person2).getList(addressProperty).add(address);
> When I run with this, I get the following exception:
> Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: Array 
> index out of range: -2
>       at 
> org.apache.tuscany.sdo.impl.ExtensibleDataObjectImpl.dynamicGet(ExtensibleDataObjectImpl.java:128)
>       at 
> org.eclipse.emf.ecore.impl.EStructuralFeatureImpl$InternalSettingDelegateMany.dynamicInverseRemove(EStructuralFeatureImpl.java:1687)
>       at 
> org.eclipse.emf.ecore.impl.BasicEObjectImpl.eDynamicInverseRemove(BasicEObjectImpl.java:1038)
>       at 
> org.eclipse.emf.ecore.impl.BasicEObjectImpl.eInverseRemove(BasicEObjectImpl.java:1027)
>       at 
> org.apache.tuscany.sdo.impl.DataObjectBase.inverseRemove(DataObjectBase.java:307)
>       at 
> org.example.person.impl.PersonTypeImpl.inverseRemove(PersonTypeImpl.java:355)
>       at 
> org.apache.tuscany.sdo.impl.DataObjectBase.eInverseRemove(DataObjectBase.java:484)
>       at 
> org.eclipse.emf.ecore.impl.BasicEObjectImpl.eInverseRemove(BasicEObjectImpl.java:1017)
>       at 
> org.eclipse.emf.ecore.impl.BasicEObjectImpl.eBasicRemoveFromContainer(BasicEObjectImpl.java:966)
>       at 
> org.eclipse.emf.ecore.impl.BasicEObjectImpl.eInverseAdd(BasicEObjectImpl.java:991)
>       at 
> org.eclipse.emf.ecore.impl.EStructuralFeatureImpl$ContainmentUpdatingFeatureMapEntry.inverseAdd(EStructuralFeatureImpl.java:3060)
>       at 
> org.eclipse.emf.ecore.impl.EStructuralFeatureImpl$ContainmentUpdatingFeatureMapEntry.inverseAdd(EStructuralFeatureImpl.java:3036)
>       at 
> org.eclipse.emf.ecore.util.BasicFeatureMap.inverseAdd(BasicFeatureMap.java:259)
>       at 
> org.eclipse.emf.ecore.util.BasicFeatureMap.addUnique(BasicFeatureMap.java:1419)
>       at 
> org.eclipse.emf.ecore.util.BasicFeatureMap.addUnique(BasicFeatureMap.java:1384)
>       at org.eclipse.emf.common.util.BasicEList.add(BasicEList.java:600)
>       at 
> org.eclipse.emf.ecore.util.BasicFeatureMap.doAdd(BasicFeatureMap.java:505)
>       at 
> org.eclipse.emf.ecore.util.BasicFeatureMap.add(BasicFeatureMap.java:1131)
>       at 
> org.eclipse.emf.ecore.util.FeatureMapUtil$FeatureEList.add(FeatureMapUtil.java:646)
>       at Test.otherTest_Static_Person(Test.java:351)
>       at Test.main(Test.java:443)
> That exception happens on the last line, the add to the copy. This only 
> happens with the official Tuscany 1.0 jars (build date of Aug 6). I've built 
> the project on July 20 and Aug 9 and neither of those throw this exception. 
> Instead of throwing the exception, those two versions have the same behavior 
> as the first case, which is still wrong. I'll attach the files to this bug. 
> Let me know if there are any questions.
> Thanks,
> -Chris

-- 
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]

Reply via email to