Community
Participate
Working Groups
The interface org.eclipse.m2m.qvt.oml.ExecutionContext does not contain a method to set a config property. The implementation class ExecutionContextImpl provides such a method, but requires explicit type casting to make it accessible. Let's extend the ExecutionContext interface.
Fixed as part of the patch for bug 391289. Besides setConfigProperty, also pulled up setLog to class ExecutionContext.
(In reply to Christopher Gerking from comment #0) > The interface org.eclipse.m2m.qvt.oml.ExecutionContext does not contain a > method to set a config property. The implementation class > ExecutionContextImpl provides such a method, but requires explicit type > casting to make it accessible. Let's extend the ExecutionContext interface. To me moving of setter methods into ExecutionContext interface is a questionable design. Methods setConfigProperty(), setLog(), setProgressMonitor() are used only upon context creation thus right after 'new ExecutionContextImpl()' expression. No type cast is needed (and in fact there wasn't any). Mentioned setters are not used during workflow. They just clutter ExecutionContext interface making the alternative implementation more difficult (like making the anonymous class instance of ExecutionContext).
(In reply to Sergey Boyko from comment #2) > Methods setConfigProperty(), setLog(), setProgressMonitor() are used only > upon context creation thus right after 'new ExecutionContextImpl()' > expression. Not necessarily right after the creation. If the setter methods are called from a different place than the instantiation, this requires to pass the context using an ExecxutionContextImpl parameter. This reads quite strange, especially from the EMF viewpoint. Not a big deal, though.