Community
Participate
Working Groups
While investigating leaks for Bug 363032, undue retention of legacy OCL instances and OCLDelegateDomain is apparent in the org.eclipse.ocl.examples.test.xtext.DocumentationExamples.testOCLinEcoreTutorialUsingLPGForLPG() test. a) EvaluationVisitorImpl.getOperation/PropertyBody does not call dispose on the OCL.newInstance b) AbstractOCLDelegateFactory.delegateDomain as a lazy cache is a residual stale reference (the pivot variant eliminates the unsafe cache altogether). c) DelegateEPackageAdapter.unloadDelegates could clear delegateDomainMap and should uninstall itself as an adapter d) DelegateResourceAdapter is never used; it should be activated by the OCLDelegateDomain constructor e) DelegateResourceAdapter.unloadDelegates is not called when d) is fixed since a Resource.RESOURCE__IS_LOADED unload notification is called after the resources have been unloaded; nothing to iterate over. Need to use Resource.RESOURCE__CONTENTS REMOVE(_MANY) notifications.
Fixes in bug/363638. Please review.
(In reply to comment #0) > While investigating leaks for Bug 363032, undue retention of legacy OCL > instances and OCLDelegateDomain is apparent in the > org.eclipse.ocl.examples.test.xtext.DocumentationExamples.testOCLinEcoreTutorialUsingLPGForLPG() > test. > > a) EvaluationVisitorImpl.getOperation/PropertyBody does not call dispose on the > OCL.newInstance > +1. > b) AbstractOCLDelegateFactory.delegateDomain as a lazy cache is a residual > stale reference (the pivot variant eliminates the unsafe cache altogether). +1. > > c) DelegateEPackageAdapter.unloadDelegates could clear delegateDomainMap and > should uninstall itself as an adapter > Ok about the map clearing... concerning the adapter uninstallation ... If the delagate domains are not loaded when the adapter is created and installed, I'm wondering why the adapter needs to be uninstalled when the delegate domains are unloaded... Anyway as I understand the code, everything is being unloaded/uninstalled when a resource is unloaded, so I guess this is Ok... > d) DelegateResourceAdapter is never used; it should be activated by the > OCLDelegateDomain constructor +1. > > e) DelegateResourceAdapter.unloadDelegates is not called when d) is fixed since > a Resource.RESOURCE__IS_LOADED unload notification is called after the > resources have been unloaded; nothing to iterate over. Need to use > Resource.RESOURCE__CONTENTS REMOVE(_MANY) notifications. +1. Regards, Adolfo.
(In reply to comment #2) Pushed to master. Thanks for the review. > > c) DelegateEPackageAdapter.unloadDelegates could clear delegateDomainMap and > > should uninstall itself as an adapter > > > Ok about the map clearing... concerning the adapter uninstallation ... If the > delagate domains are not loaded when the adapter is created and installed, I'm > wondering why the adapter needs to be uninstalled when the delegate domains are > unloaded... Anyway as I understand the code, everything is being > unloaded/uninstalled when a resource is unloaded, so I guess this is Ok... For most usage cleaning up is done automatically as an application stop. The scenario that worries me is a potentially infinite CDO session with resources coming and going. We must not leave support for obsolete resources lying around. The JUnit leakage sensitivity is the best exercising we currently have of this scenario.
Core Builds and Tests ok.
CLOSED after a year in the RESOLVED state.
