[
https://issues.apache.org/jira/browse/TUSCANY-1565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Frank Budinsky resolved TUSCANY-1565.
-------------------------------------
Resolution: Cannot Reproduce
I tried it with the latest from HEAD, and there was no exception. I guess it's
a bug in the 1.0 release that has since been fixed.
> 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]
