Good remark Guillaume.
What about storing executionsScopes used by extensions in the environment ? This way executionScopes could be used only in pvm core to manage NestedExecutionScopes used to go back to parent...
In addition, for the moment executionScopes is pretty hard to use as we can find objects in this stack that we never push like nestedExecutionScopes...
you guys have a point. there is a relationship between environment contexts and execution scopes
the first purpose of the environment is to provide a separation between the environment and the engine so that it can run in standard and enterprise java. Also all other configurations can be managed in the application scope of the environment.
the usage as separator between environment and engine is clear and pretty much stable.
but beyond that, the environment has other possibilities. it can manage a set of contexts related to e.g. the process execution, the process definition, or even a web session.
then we can start searching in the contexts. that is a really nice feature for EL expressions. the variables are resolved in all of the contexts.
executionsScopes could be installed as contexts in the environment. But in these situations things get a bit more fuzzy for me.
cause we have to take into acount the persistence and other use cases. if you want to install al the nested scopes as contexts, that might imply that whenever you start executing on a certain execution, you need to walk over the full stack of executionScopes to actually install them in the environment. that might be overkill.
instead, i'm more thinking of a process variable context. that has a pointer to an execution and that knows how to search for variables in that execution's executionScope stacks.
do you guys see the same tradeoffs ?
what is your opinion ?