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