Community
Participate
Working Groups
Created attachment 219911 [details] Example app It looks like RAT is only track direct IEclipseContext access but not those done through @Inject and most important for e4 e.g. @CanExecute. Run the attached app and see that @CanExecute stuff does not work. I'll mark this as a major bug because it is a requirement for none timerbased toolitem enable/disablement.
Created attachment 219958 [details] Patch showing the place where this happens The @CanExecute is usually called (from EHandlerService etc) through the invoke method of the injector (InjectorImpl). This methdod calls the invokeUsingClass method which explicitly tells the object supplier not to track the args in two places (the result in the end is the ANDing of the two): -MethodRequestor constructor -resolveArgs method call. I don't know if this is by design but changing them to true worked in re-calling the method (the odd-even check in the sample project is made fine). Now I'm not sure of the implications of this change as it is in the heart of the injector so the patch is just meant to show where the issue lies. Maybe some overloading or something else might be a better solution.
(In reply to comment #0) > Created attachment 219911 [details] > Example app > > It looks like RAT is only track direct IEclipseContext access but not those > done through @Inject and most important for e4 e.g. @CanExecute. Do you mean "invoke" (not "inject")? > > Run the attached app and see that @CanExecute stuff does not work. I'll mark > this as a major bug because it is a requirement for none timerbased toolitem > enable/disablement. By design, #invoke() is a single call, not meant to be repeated automatically. We take data for its arguments from the context, but it is assumed to be a one-time thing; we don't repeat those calls when argument values change. Injected values we track; #invoke() we do not track. The "@CanExecute" is a form of #invoke(). (By the way, another thing while on the subject: we only track directly injected arguments. If a user code uses injected value A to get value B, we do not track B.) As far as DI goes, this is very much by design. In SDK, "CanExecute" is mostly used by handler processing; "invoke" is used in a number of places. I would refrain from changing "invoke" in a non-backward compatible way. The "CanExecute" - I'll leave up to Paul as he seems to be the main consumer. Personally, it is highly visible so I'd prefer to deprecate / remove "CanExecute" and replace it with something else rather than change functionality so drastically.
