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

Bug 338501

Summary:	[environment] Clarify status of the global environment
Product:	[Modeling] OCL	Reporter:	Ed Willink <ed>
Component:	Core	Assignee:	OCL Inbox <mdt-ocl-inbox>
Status:	NEW ---	QA Contact:
Severity:	normal
Priority:	P3	CC:	eclipse
Version:	3.1.0
Target Milestone:	---
Hardware:	PC
OS:	Windows Vista
See Also:	https://bugs.eclipse.org/bugs/show_bug.cgi?id=543221 https://bugs.eclipse.org/bugs/show_bug.cgi?id=570995
Whiteboard:

Description Ed Willink

2011-03-01 01:04:21 EST

Usage of the default and consequently global environment has recently been discouraged, if not formally deprecated, since in the context of evaluation the global environment implies a model extent of all registered packages which is expensive for allInstances() and model analysis.

A different usage of the global environment occurs for OCLDelegateDomain where a shared EMF extending service is provided for all applications. This should not use an environment that favours the first application to activate the delegate domain, so should use the default global environment.

Perhaps there should be a different default environment that is almost/totally empty for use by OCLDelegateDomain. Perhaps the sole default environment should be almost empty.

Comment 1 Axel Uhl

2011-03-02 06:53:25 EST

(In reply to comment #0)

Ed,

> Usage of the default and consequently global environment has recently been
> discouraged, if not formally deprecated, since in the context of evaluation the
> global environment implies a model extent of all registered packages which is
> expensive for allInstances() and model analysis.

can you be a bit more specific as to which "environment" you mean? The EcoreEnvironment instances? Or the EcoreEvaluationEnvironment instances? Or the OCL object(s)? Which part of allInstances() evaluation are you referring to? The LazyExtentMap implementation scans the entire resource/resource set, regardless of the packages in the EPackage registry. So I'm not sure I understand what you mean.

> Perhaps there should be a different default environment that is almost/totally
> empty for use by OCLDelegateDomain. Perhaps the sole default environment should
> be almost empty.

Probably, after you detailed the above it also becomes clearer what you mean by "almost/totally empty."

Best,
-- Axel

Comment 2 Ed Willink

2011-03-02 12:41:00 EST

This is a somewhat philosphical memo to do some analysis and then design something sensible for all global objects that may be shared by multiple applications.

A related problem that made me appreciate this inadequacy arises with DelegateDomains targeting a pivot.

The delegate domain provides an extended EMF, but the application using the delegated OCL may use one of a variety of different OCL standard libraries. If one application has an overloaded OclAny::= and another doesn't, which OCL is used? Not actually a pivot problem, just that the pivot is cached for the selected semantics, so it highlights the inflexibility.

Since the delegate domain cannot know which application's OCL semantics to use, it must use none of them and instead always use the neutral semantics that the releng feels is appropriate for all users.

Comment 3 Ed Willink

2011-03-08 08:40:58 EST

Note that in https://bugs.eclipse.org/bugs/show_bug.cgi?id=339052 we discovered that:

A: a delegating registry doesn't delegate the values() call to enumerate candidate packages.

B: the package lookup of values() ignores packages whose package delegate has not already been resolved.

Conclusions: B: the use of the 'global package registry' may give interminttent results. A: delegation to 'the global package registry' is almost useless.

Users must therefore create and populate a custom package registry. Deprecation of the global registry can therefore be quite aggressive.

Comment 4 Ed Willink

2011-05-05 14:54:44 EDT

Deprecation of the global environment can exploit the introduction of an EnvironmentFactory EPackage EAnnotation.

Comment 5 Ed Willink

2021-02-14 07:03:30 EST

(ntroduction of a LocalThreadExecutor for Bug 570995 suffers fromthe concurrent Global/non-GloablEnvironmentFactory and highlights a solution.

Using the LocalThread the 'global' shared context can be 'local'.

Comment 6 Ed Willink

2021-02-22 13:23:29 EST

The Pivot GlobalEnvironmentFactory is obsolete as of 6.14.0M3.

The Pivot OCLDelegateDomain.ocl is probably obsolete - needs review

THe Pivot QveryImpl has been abstracted as BasicQueryImpl without an OCL - needs review

---

The Classic OCL could also move to a ThreadLocal ...