2 Replies Latest reply on Aug 15, 2007 9:09 AM by Tom Baeyens

    Differences between ExecutionScope and Environment contexts

    porcherg Novice

      I wonder how the environment will be used in the pvm. In the environment, we can add and remove contexts at runtime. We have one environment per thread (only the application context is shared between threads).
      Each time we search for an object in the environment, we first search in the last added context and if no object is found, we search in the previous one...

      In ExecutionController, we have a executionScope. If I understand well, it is a stack where we push objects needed by the execution.

      Where should we put runtime variables ? in an environment context or in the execution scope ?
      What should be defined in the execution and what should be in the environment ?

      regards,
      Guillaume

        • 1. Re: Differences between ExecutionScope and Environment conte
          Charles Souillard Newbie

          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...

          Charles

          • 2. Re: Differences between ExecutionScope and Environment conte
            Tom Baeyens Master

            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 ?