Description Pierre-Charles David 2016-02-03 05:35:29 EST

Currently it is very easy to call arbitrary Java code from inside a VSM by writing a Java class which follows the "service" conventions (https://www.eclipse.org/sirius/doc/specifier/general/Writing_Queries.html#service_methods). However, these conventions are rather weak (which is a good thing in most cases), and once inside the Java code the only input is the "self" EObject on which the service was called. Any potentially useful information about the context in which the service was call has been lost. When such information is needed it must be re-computed at sometimes non-trivial costs inside the service method. Because we offer no guarantee on the lifecycle of the service classes instances, these result can not even be cached and must be re-computed on each invocation.

A possible improvement would be to allow optional injection by Sirius of some of the most commonly used context information directly inside the service class. For example, a service class could look like this:

public class MyServices {
  @Inject private Session session;

  public EObject someService(EObject self) {
    if (session != null) {
      // When invoked by Sirius from the context of a Session, the session's value will have been injected.
    } else {
      // It is still possible for the service to be invoked from other contexts (e.g. raw AQL outside of Sirius), so the service should be ready for it.
    }
  }
}

Some potentially useful candidates for injection, that many services in concrete modelers end-up re-computing themselves:
* Session
* TransactionalEditingDomain
* ResourceSet
* IInterpreter (with access to the variables)
* maybe others

Note that technically Session is enough to easily obtain the other examples listed above, but if the service only needs the ResourceSet it's a good idea not to make it dependant of the whole Session type.

Note also that injecting IInterpreter can be used by the service to evaluate expressions, which means the interpreters being used must be reentrant (the service invocation itself being probably done in the context of evaluating an expression). It is obviously already possible to obtain the IInterpreter, but I'm not sure all interpreters support reentrant calls correctly. If we explicitly/officially support injecting IInterpreter, we will need to ensure this works (at least for the core interpreters and AQL).