Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 347644

Summary:

[delegates] Constraint cached not refreshed by Ecore change

Product:

[Modeling] OCL

Reporter:

Ed Willink <ed>

Component:

Core

Assignee:

OCL Inbox <mdt-ocl-inbox>

Status:

CLOSED FIXED

QA Contact:

Severity:

normal

Priority:

CC:

eclipse

Version:

3.1.0

Target Milestone:

Indigo

Hardware:

OS:

Windows Vista

Whiteboard:

Attachments:

Description	Flags
Eliminate delegate domain cache	none

Description Ed Willink

2011-05-30 08:36:40 EDT

Following the OCLinEcore tutorial, create Tutorial.xmi and validate to show the 3 loans for 2 copies validation error.

Upgrade the Ecore to have a custom message or just a different Invariant name spelling

Result: OCLDelegateException for Missing or invalid body constraint for 'null'

Problem is that the the AbstractOCLDelegateFactory which is initially created for the delegateURI caches the lazily created OCLDelegateDomain. THis is sound when meta-models are stable since why recreate. However if the meta-model changes the cache can be stale, which is insidious for the pivot model since the TypeManager for the Pivot counterparts of the Ecore is cached in the OCLDelegateDomain that is cached in the factory.

Need to provide strong bidirectional Ecore <=> Pivot synchronization.

Comment 1 Ed Willink

2011-05-30 11:07:25 EDT

Created attachment 196910 [details]
Eliminate delegate domain cache

For the pivot model, the persistence of a TypeManager in the cache is clearly invalid. Attached therefore eliminates it and adds a test to demonstrate flipping between Ecore resource versions.

For the mature code, it may take some quite detailed white box study to contrive a similar failure; certainly not an activity for RC3.

Please +1 the attached for the Pivot Model at RC3.

Comment 2 Axel Uhl

2011-05-30 11:39:54 EDT

Ed, isn't the OCLDelegateDomain still cached in DelegateEPackageAdapter.delegateDomainMap? This cache seems to be relied upon also by the call to ePackageAdapter.getDelegateDomain(delegateURI) that your patch now does every time. If the EPackage is changed without entirely discarding and reloading it (e.g., by an in-place editing), the DelegateEPackageAdapter will reside in the package's adapters list, and so will its delegateDomainMap cache. Why is the patch only dealing with the more local cache in AbstractOCLDelegateFactory?

Comment 3 Ed Willink

2011-05-30 11:49:44 EDT

(In reply to comment #2)
> Ed, isn't the OCLDelegateDomain still cached in
> DelegateEPackageAdapter.delegateDomainMap?

Yes, but the DelegateEPackageAdapter is for an EPackage object so a reload creates a different Epackage and so different DelegateEPackageAdapter. The problem arises when caches are located by a String behind which an EObject chances unnoticed.

Comment 4 Axel Uhl

2011-05-30 11:59:05 EDT

Understood. Then: +1

Comment 5 Ed Willink

2011-11-08 13:35:11 EST

This was committed in May.

Comment 6 Ed Willink

2013-05-20 11:36:42 EDT

CLOSED after a year in the RESOLVED state.