[
https://issues.apache.org/jira/browse/TUSCANY-1095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12470365
]
David T. Adcox commented on TUSCANY-1095:
-----------------------------------------
Here's is a sample of code that demonstrates the problem...
public class DynamicTypeIssue
{
public static void main(String[] args)
{
String namespace = "http://namespace";;
// type 1
DataObject type1 = DataFactory.INSTANCE.create("commonj.sdo", "Type");
type1.set("uri", namespace);
type1.set("name", "type1");
type1.setBoolean("abstract", true);
type1.setBoolean("sequenced", true);
Type type1Type = TypeHelper.INSTANCE.define(type1);
// type 2
DataObject type2 = DataFactory.INSTANCE.create("commonj.sdo", "Type");
type2.set("uri", namespace);
type2.set("name", "type2");
type2.setBoolean("sequenced", true);
List baseTypes = new ArrayList();
baseTypes.add(type1Type);
type2.setList("baseType", baseTypes);
TypeHelper.INSTANCE.define(type2);
}
}
This sample will generate a null pointer exception. That issue is caused when
the Document Root can't be located, after it has been created. Upon debugging
the issue, you will see that the document root is lost, due to the removal of
the 'type1' type from the ePacakge's list of eClassifiers. This is really the
root of the issue.
> "baseType" properties on DataObjects are using the wrong base EMF list class
> ----------------------------------------------------------------------------
>
> Key: TUSCANY-1095
> URL: https://issues.apache.org/jira/browse/TUSCANY-1095
> Project: Tuscany
> Issue Type: Bug
> Components: Java SDO Implementation
> Affects Versions: Java-SCA-M3, Java-SCA-Mx, Java-SDO-Mx
> Environment: n/a
> Reporter: David T. Adcox
> Fix For: Java-SDO-Mx
>
>
> There is a problem when setting the "baseType" property on a DataObject.
> Specifically, if a new Type is being dynamically created, when a parent type
> is specified in the "baseType" property, upon setting that property, the
> parent type is taken out of the ePackage to which it belongs. It seems the
> list type being used checks for containment. That should not be a
> consideration in this case. I'll attach a sample of code demonstrate this
> behavior.
--
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]
