[e4-dev] Context recording w/ RunAndTrack and ContextObjectSupplier

[Simon Chemouil <eclipse@xxxxxxxxxxxxxx>]

Hi there!

I think this is Oleg's area of expertise... (I hope to catch his eye :)

I'm currently moving our application to "4.1" (or org.eclipse.e4 0.10.0
I think), using the Indigo release. It's going surprisingly well, but as
expected I've spotted a few bugs/problems that either:
(1) I can work around in client code
(2) Are clearly bugs that I have reported/will report and provide
patches for
(3) I have no idea why this was changed :)

I've found a problem of the (3rd) kind today regarding Context recording
(for RunAndTrack) and ContextObjectSupplier.

Here's our scenario:
- We have developped a util class that binds a widget (such as Buttons,
ToolItems, MenuItems, ...) to a commandId in a given eclipseContext
- This class uses a runAndTrack Runnable that calls
handlerService.canExecute(boundCommand);

Since it's tracked in a RAT call, our runnable will be called only on
context computations that were called the first time, and in my case I'm
particularly interested in the injected parameters of my handler's
@CanExecute

Those parameters are resolved by a ContextObjectSupplier instance.

Problem is, since 4.1, ContextObjectSupplier does _not_ "record/track"
access when doing a simple "get" (it still does for tracking injection
such as @Inject calls).

Code in ContextObjectSupplier:

line 162:
			if (descriptors.length > 0) {
				pauseRecording();
				try {
					fillArgs(actualArgs, keys, active);
				} finally {
					resumeRecoding();
				}
			}

If I remove pauseRecording(); and resumeRecording(), my util class works
just fine, the context access is recorded and the context RAT knows that
it must call my runnable when any of these will change....


Why was this changed? Obviously there is a performance factor, but I
think my usage was valid. An ugly workaround would be to force the
context resolution of the @CanExecute parameters from my class, but that
would involve to introspect it twice more.

Another possibility is to give client access to whether our
EHandlerService#canExecute() will track context access...?

In any case, for now the solution I will likely go for is to use/provide
the patched core.contexts bundle but I try to stay on the E4 mainline so
discussion / reflexion is more than welcome.

Cheers,

-- 
Simon