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

Bug 474334

Summary: AcceleoEvaluationException on a diagram after a new element's creation in a table
Product: [Modeling] Sirius Reporter: Stéphane Thibaudeau <stephane.thibaudeau>
Component: CoreAssignee: Pierre-Charles David <pierre-charles.david>
Status: CLOSED FIXED QA Contact: Laurent Redor <laurent.redor>
Severity: normal    
Priority: P3 CC: laurent.redor, pierre-charles.david
Version: 2.0.5Keywords: triaged
Target Milestone: 2.0.7   
Hardware: PC   
OS: Windows 7   
See Also: https://git.eclipse.org/r/54458
https://git.eclipse.org/r/54459
https://bugs.eclipse.org/bugs/show_bug.cgi?id=461498
https://git.eclipse.org/c/sirius/org.eclipse.sirius.git/commit/?id=33dd0e9a960ec1f73411ee7059c3beb8806fd328
Whiteboard:
Attachments:
Description Flags
Example project
none
Menu used to create a new user story none

Description Stéphane Thibaudeau CLA 2015-08-05 11:12:50 EDT 
Created attachment 255648 [details]
Example project

In my project, I have a diagram and a table.
Both are displayed with no problems.
When I add a new element using the table, the diagram starts to log AcceleoEvaluationExceptions.
Please note, that the new element has probably no impact on the diagram. When closing the project and reopening the diagram everything is working fine.


Steps to reproduce :

1- install Graal modeler, using the update site at http://update.obeo.fr/integration/informationsystem/4.0/design/repository/
2 - import the test project using the provided archive
3 - clean the error log
3 - open the "Tasks graph" and "User stories table" representations. You should see nothing in the error log
4 - in the "user stories table", use the "user story" menu in the toolbar to create a new User story
5 - warning and error should be visible in the error log now. When a refresh is done on the diagram new error and warning appear.
The error is a NullPointerException, it is caused by the first warning (AcceleoEvaluationException). A first call causes this warning, and then a "null" is sent to another service, causing the NPE.
Comment 1 Stéphane Thibaudeau CLA 2015-08-05 11:13:31 EDT 
Created attachment 255649 [details]
Menu used to create a new user story
Comment 2 Stéphane Thibaudeau CLA 2015-08-05 11:52:03 EDT 
The previous update site contains the same versions I've been usiing for my tests. If it's not available you should probably reproduce the bug using this update site :
http://marketplace.obeonetwork.com/updates/sirius2.0
Comment 3 Pierre-Charles David CLA 2015-08-06 04:08:37 EDT 
Reproduced using the supplied data.
Comment 4 Eclipse Genie CLA 2015-08-25 05:52:27 EDT 
New Gerrit change created: https://git.eclipse.org/r/54458
Comment 5 Eclipse Genie CLA 2015-08-25 05:53:29 EDT 
New Gerrit change created: https://git.eclipse.org/r/54459
Comment 6 Pierre-Charles David CLA 2015-08-25 06:00:12 EDT 
Analysis of what happens:
* When the diagram is opened, many Acceleo expressions are evaluated in the context of the diagram. This evaluation requires the generation and compilation of in-memory MTL modules, both for the expressions themselves and for the services declared in the VSM. In particular, the VSM reference to the TaskUtils service class produces an MTL module with this signature:

  [module org::obeonetwork::graal::design::services::task::TaskUtils('http://www.obeonetwork.org/dsl/graal/2.0.0','http://www.eclipse.org/sirius/diagram/1.1.0')]

  which declares queries on all service methods in TaskUtils, using the special invoke() instruction. At this point, all the expressions (including the service modules) are in a context where at least one variable (e.g. "diagram") is instance of the http://www.eclipse.org/sirius/diagram/1.1.0 Sirius metamodel. The Sirius/A3 bridge sees this implied dependency, and correctly adds the diagram metamodel to the compilation context. The TaskUtils module compiles without errors, and everything goes fine.

* Then we open the table, which also evaluates Acceleo expressions, but in a different context. This time, none of the variables reference the diagram MM, so when the time comes to recompile the TaskUtils module, the signature used is

  [module org::obeonetwork::graal::design::services::task::TaskUtils('http://www.obeonetwork.org/dsl/graal/2.0.0')]

  This version does not compile, which results in a CompilationResult instance with many ERRORs in its status, but which is still put in the compiledModules cache. The table does not use this service, so its own refresh goes fine.

* When the table tool is invoked, its own execution goes fine too, but it changes the semantic model, which triggers a refresh on the diagram side. When the diagram expressions are evaluated, they find the erroneous CompilationResult in the cache, and use that despite its error status, instead of re-compiling the module in the current contect. This makes the resolution of the expression's AST fail; more precisely, when parsing the expression begin evaluated, the call to "source.resolveAST();" in AcceleoParser.parse(AcceleoSourceBuffer, Resource, List<URI>) produces a QuerySpec for "visibleTasks(DDiagram)" with expression == null, which causes the error seen in the error log.

The proposed fix is to backport the patches made for bug #461498 (fixed in 3.0), which always make all our dialects' metamodels available to the context of expression, including the Acceleo compilation context.
Comment 8 Pierre-Charles David CLA 2015-08-26 05:25:28 EDT 
Fixed by 33dd0e9a960ec1f73411ee7059c3beb8806fd328.
Comment 9 Laurent Redor CLA 2017-01-04 03:20:17 EST 
Validated with Sirius 2.0.7 (2.0.7.201611241521)
Comment 10 Pierre-Charles David CLA 2017-01-31 08:49:44 EST 
Available in Sirius 2.0.7, see https://wiki.eclipse.org/Sirius/2.0.7.