[ https://issues.apache.org/jira/browse/TUSCANY-1565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Chris Mildebrandt reopened TUSCANY-1565: ---------------------------------------- Thank you for the clarification on the specification. I understand that case now. I regenerated my classes with the Tuscany 1.0 jars and see the same exception. Please let me know if you have any additional questions. Thanks, -Chris > 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]