Community
Participate
Working Groups
Using the mature delegates, if an OCL constraint is cached that uses a type reference, e.g. oclIsKindOf(A2) then the cache contains a pointer to the Resource in the prevailing application ResourceSet. A subsequentr reuse by another application. e.g. the Sample Reflective Ecore Editor again, fails since the objects are from one ResourceSet and the OCL from another. either: applications should be forced to use a ResourceSet-specific delegate registry, or: OCL must not cache type references or must refresh the cache to accommodate prevailing ResourceSets.
This is so evil that both approaches should be adopted. Currently with the Global registry is being used by default, whenever any application invokes an OCL delegate, that application's ResourceSet may get locked in memory and no doubt much else belonging to that application too. It is just not safe for anything other than boring constant expressions to be cached in the Global registry, therefore the OCL fix must be to disable caching when the Global registry is in use. Thereafter other applications may restore cache benefits by explicitly specifying ResourceSet-specific delegate registries.
I would expect type references to usually go to the contents that are in the central EPackage.Registry.INSTANCE and therefore shared anyhow. Under which circumstances are the type elements in specific editor's resource sets?
If using reflective EMF, the types will always be in the user's reflective space. If using a private ResourceSet, as we strongly recommend for OCL, user types will also be in the unshared application space; new invocation -> new ResourceSet -> new Resource -> new EClass, so TypeExp.referredType may lock in historic context. Potentially referredOperation and referredProperty may also have issues.
(In reply to comment #3) Not sure I fully understand what you mean by "reflective EMF." I've been running a test with a specific Ecore metamodel that registers with the Ecore Package registry using the respective extension point. When I open an editor that uses its separate ResourceSet, select an element of a type taken from the registered metamodel and enter an expression "self.oclIsKindOf(SomeTypeFromTheMetamodel)" then the debugger shows that the referredType reference points to an EClass that is in a Resource that's not in a ResourceSet and is taken from the central package registry. If I do the same for a selection in a different editor with an equal expression from the Interactive OCL console, the same referredType EClass is referenced. Therefore, at least with this scenario it seems impossible to reproduce what you're describing. Can you maybe provide a reproduction scenario?
Reflective Ecore is when there is no genmodel-led Java, or when a resource is loaded as a file rather than registered URI, resulting in the creation of a per-load Resource. At least registered Resources are not a problem, so we can be less draconian on a refusal to cache. Disable Delegate Registry cacheing when a candidate OCL expression AST node references an EObject that is in a different ResourceSet to that containing the EPackage/EClass/... for which delegation supports a Constraint. This is an asymmetric difference, AST nodes with references to EObjects in the null ResourceSet may be cached anywhere. Delegates in the null ResourceSet (the global delegate registry) may not cache AST nodes with references to EObjects in any non-null ResourceSet. The edit, then second edit fails scenario is irritating. The run, edit, then rerun fails scenario is much worse and confusing for users.
(In reply to comment #5) This would probably mean that before caching we need to check *all* references made by the AST to anything that looks like an Ecore element (class, data type, property, reference, attribute, ...). If any of them lives in a non-null ResourceSet, caching would need to be disabled, right?
(In reply to comment #6) > This would probably mean that before caching we need to check *all* references > made by the AST to anything that looks like an Ecore element (class, data type, > property, reference, attribute, ...). i.e. any EObject > If any of them lives in a non-null > ResourceSet, caching would need to be disabled, right? No. If their ResourceSet has a DelegateResourceSetAdapter that provides the DelegateRegistry in which the OCL AST is being cached then it's a safe consistent local usage. See DelegatesTest.setUp() where local DelegateRegistry instances are created. Typical algorithm, almost in OCL. oclExpression->eAllContents()->including(oclExpression).eResource().getResourceSet()->asSet()->excluding(null) gives all resource sets, which must all use the same OCLDelegateDomain as the cache if caching is to occur. Disabling OCL cacheing fixes the memory lock-ins. A patch is needed for EMF to facilitate ResourceSet-specific Delegate Registries.
Note that we've been referring to the creation of instances from an Ecore model for which there is no generated code as dynamic EMF not reflective EMF. http://www.devx.com/Java/Article/29093/0/page/1 http://www.ibm.com/developerworks/library/os-eclipse-dynamicemf/
The availablility of direct code generation reduces the need to fix this.
Fixed as part of Bug 363638.
CLOSED after a year in the RESOLVED state.
