[ 
https://issues.apache.org/jira/browse/TUSCANY-1322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12500836
 ] 

Frank Budinsky commented on TUSCANY-1322:
-----------------------------------------

I can see that the generated Test1322FactoryImpl class has not been regenerated 
with the latest template. If you look at the generated initializeMetaData 
method you'll see that it's calling FactoryBase.getProperty() which has been 
deprecated as part of TUSCANY-1305. If you regen, you'll see that it should now 
be calling a new method, getLocalProperty().

Like I said in my first comment, this problem has already been fixed. Please 
regen your model and try again.


> Static code gen objects not deleting contained children successfully
> --------------------------------------------------------------------
>
>                 Key: TUSCANY-1322
>                 URL: https://issues.apache.org/jira/browse/TUSCANY-1322
>             Project: Tuscany
>          Issue Type: Bug
>          Components: Java SDO Implementation
>    Affects Versions: Java-SDO-M2
>         Environment: n/a
>            Reporter: David T. Adcox
>            Priority: Minor
>             Fix For: Java-SDO-1.0
>
>         Attachments: Tuscany1322.patch, Tuscany1322.zip
>
>
> The SDO 2.1 specification states the following on page 17:
> The delete() method unsets all the DataObject's non-readonly properties. The 
> delete()
> method will also remove the DataObject from its containing DataObject if the
> containment Property is not read-only. All DataObjects recursively contained 
> by
> containment properties will also be deleted.
> So, it is expected that the contained DOs will delete their contained DOs, 
> and so on, until all DOs have been released under the DO where the delete() 
> method was called.  This behavior seems to be working correctly in the case 
> of dynamic DOs, but statically generated DOs are not functioning properly.  
> The contained DOs are still held by their containing DOs.  
> This fault seems to be caused by a failure in how containment is being 
> tracked in how the underlying EMF code was initialized.  The root cause of 
> the failure is a combination of how EMF manages the 
> EClassImpl.eAllStructuralFeatures and how SDO static object types are 
> initialized.  In the EClassImpl object, the eAllStructuralFeatures tracks 
> containment properties via a sub-list.  This sub-list is created ONLY one 
> time.  eAllStructuralFeatures is created the first time, when it is first 
> requested.  For static SDO-based applications, this first time is somewhat 
> random depending on the property types being created.  During static SDO init 
> there are two key functions of note; the createMetaData() method and the 
> intializeMetaData() method.  The createMetaData() method is called first, and 
> all DO properties have an 'empty' properties object created and attached to 
> the DO type.  Then, the initializeMetaData() method is called.  This method 
> 'configures' each of the blank property objects.  The problem is that the 
> eAllStructuralFeatures containment list is constructed early in the 
> initializeMetaData() method, before all the properties have been initialized. 
>  So, not all containment properties are recognized and therefore placed into 
> the eAllStructuralFeatures containment list.  This then affects the behavior 
> of the DataObjectUtil.delete(DataObject), such that it doesn't properly pull 
> all the contained DOs.
> Attached is a zip file with source code and a test schema.  In the zip is the 
> test client and associated static code gen classes.  

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